addiks / phpsql Goto Github PK

Currently there are no transactions. Trying to start a transaction will result in an error.

It should be possible to start, commit and rollback transactions using the statements 'START TRANSACTION', 'COMMIT' and 'ROLLBACK'.

Implementation plan: I think the easiest way to implement transactions is using a proxied filesystem that saves all changes in a seperate (inmemory) file and only applies these changes on a commit. Read actions on a file with uncommitted changes has to be managed correctly.

The structure of the data stored on the file-system can change with every version. Currently every structure-change can (and in most cases will) make the already stored files incompatible.

The structure of the stored files should be versioned, every version should be readable (by the latest phpsql-version) and migrations to higher versions should be possible.

Implement views. Most of that should already be there. Just connect the dots.

There is a hard requirement in CreateTableStatement.php:checkPlausibility() for tables to have a primary key- however this is not a SQL requirement. The library incorrectly adds a primary key to the first column in the table which breaks when that column does not contain unique values.

Currently the meta-database 'information_schema' does not work and any try to access it will result in an error.

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.