Clear up division of labour
This commit is contained in:
parent
53c5d3f3f7
commit
c4de02c1e6
1 changed files with 12 additions and 14 deletions
|
|
@ -1,21 +1,19 @@
|
||||||
|
|
||||||
Communication with client (mainly processing client's input)
|
Communication with client (mainly processing client's input)
|
||||||
* understand and implement the postgres protocol
|
* understand and implement the postgres protocol
|
||||||
* setup of concurrent connections
|
* setup of concurrent connections
|
||||||
* when client sends a query, we send it to the parser "component"
|
* when client sends a query, we send it to the parser
|
||||||
|
|
||||||
Parsing can be started now
|
Parsing can be started now
|
||||||
basically a function
|
basically a function
|
||||||
String -> Result<Operation, ParsingError>
|
String -> Result<RawOperationSyntax, ParsingError>
|
||||||
|
|
||||||
Validation of operation
|
Validation of operation
|
||||||
When parsing gives you an operation, it need not make sense (e.g. table doesn't exist)
|
When parsing gives you a raw syntax of an operation, it need not make sense (e.g. table doesn't exist)
|
||||||
So we need to validate the operation.
|
So we need to validate it.
|
||||||
The output of the validation is
|
The output of the validation is
|
||||||
* relevant table
|
* a proper operation validated against the database schema
|
||||||
* an "augmented" operation (e.g. operation with type operation)
|
|
||||||
* reject when e.g. table doesn't exist, condition refers to non-existent column etc
|
* reject when e.g. table doesn't exist, condition refers to non-existent column etc
|
||||||
* This phaze doesn't need access to rows nor indices, just table meta-data.
|
* This phaze doesn't need access to runtime data (e.g. rows or indices), just the table schemas.
|
||||||
|
|
||||||
==========Locking of tables should happen here========
|
==========Locking of tables should happen here========
|
||||||
|
|
||||||
|
|
@ -30,9 +28,9 @@ Responding to the client
|
||||||
==========Lock on the table should be dropped here===========
|
==========Lock on the table should be dropped here===========
|
||||||
|
|
||||||
Serialization/Desearilization to disk
|
Serialization/Desearilization to disk
|
||||||
* There are two approaches, one is incremental (and very hard)
|
There are two approaches
|
||||||
the other is: when the server is shut down.
|
* one is incremental (and very hard), a storage engine where you have a huge database on disk
|
||||||
|
encoding something like a BTree, and then you have a small in-memory view (cache) on what's on the disk.
|
||||||
|
And you try to constantly keep these synced.
|
||||||
|
* the other is: when the server is shut down, just serialize the in-memory database state onto disk
|
||||||
|
in e.g. JSON. Trivial to implement.
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue