Currently there is no locking at all. For in-memory databases (without threads) this is not a problem, but it will become a problem when the database is saved on the actual filesystem.
There must be a way to lock tables or rows.
Implementation plan: While the table- and column-data- implementations work with the actual files, the executors use abstract data-providers (filters, orderers, ...) that themself use arbitrarely deep nested the actual implementations. That means we need an Interface (LockableInterface) that indicates that this data-provider can be locked. The column-data/table/schema implementations will do actual locking and the other data-providers will just forward the lock-operations. Maybe have the actual locking done by a seperate class of components (Lockers?) that can depending on the implementation either just use the 'flock' functions or use more complex semaphores.
Currently there is no locking at all. For in-memory databases (without threads) this is not a problem, but it will become a problem when the database is saved on the actual filesystem.
There must be a way to lock tables or rows.
Implementation plan: While the table- and column-data- implementations work with the actual files, the executors use abstract data-providers (filters, orderers, ...) that themself use arbitrarely deep nested the actual implementations. That means we need an Interface (LockableInterface) that indicates that this data-provider can be locked. The column-data/table/schema implementations will do actual locking and the other data-providers will just forward the lock-operations. Maybe have the actual locking done by a seperate class of components (Lockers?) that can depending on the implementation either just use the 'flock' functions or use more complex semaphores.