ornamental / kvp-store Goto Github PK

Currently the data is read from the record into a byte array (fully). The interface allows to return a more general accessor based on channels, which has to be used.

The instances of Table may now be passed as arguments to many methods where table name is expected.

The ORM functionality is not employed at all as only raw SQL queries are sent to SQLite. Thus there is no need in using ORMLite, JDBC functionality combined with connection pooling should be sufficient.

1. Implement JDBC connection pooling.
2. Consider preparing certain statements on per-connection basis (as there will be only one RW connection, the INSERT, UPDATE, and DELETE statements only have to be prepared for this connection; RO queries will have to be prepared for each connection in the pool).
3. Migrate to the new querying mechanism and exclude the dependencies which will become redundant.

Requirements

1. The storage must support any number of concurrent readers and one writer not blocked by the readers.
2. Each reader must observe the snapshot of the storage relevant at the moment of its creation; it must not see the changes added afterwards, either committed or not.
3. The writer must observe the most relevant state with its own uncommitted changes.
4. The writer must support commit and rollback operations.
5. However much data a writing transaction might supply, the RAM footprint must not grow proportionally.
6. The storage must be able to transfer data from byte arrays, input streams, and readable byte channels.

Supplying the parameters other than those specified upon the creation of the storage shall lead to undefined storage behaviour. Most parameters have to be saved as a part of the storage metadata and automatically restored when the storage is reopened.

The user should be able to specify the offset and length upon instance creation.