👾 An Evolutionary Database System for Modern Hardware
SirixDB is an evolutionary, accumulate-only database system. Each new commit stores more data in a new snapshot, which shares common data with the previous revisions. The system never overwrites data. It supports a single read-write transaction per resource concurrently to N read-only transactions. Furthermore, in stark contrast to other database systems, the persistent, durable tree consists of variable-sized database pages. Versioning takes place at a sub-page level according to a novel sliding snapshot algorithm.
We have a lot of issues to work on. I'll list some of them for which you don't have to have a database background:
New logo and/or Logo for the Forum
#85
We are missing a logo in the size 64×64 for the Forum, such that we have a start logo for Android mobile phones...
Create a Kotlin HTTP-Client
#251
Similar to the Python and TypeScript Client we should provide a Kotlin Client.
Create Java9 and above module-infos.
#60
In order to use Jigsaw/the module system, we should write module definition files.
Implement a JsonStreamingShredder based on Vert.x JSON streaming parser
#282
Thus, we can omit storing first a temp JSON file in the HTTP-Server:
https://vertx.io/docs/apidocs/io/vertx/core/parsetools/JsonParser.html
Update REST-API to Vert.x 4 Beta 1
#297
We should update the REST-API (server-rest-api bundle) to Vert.x 4 Beta 1. Some stuff has been deprecated, though.
Add a compile time DI framework
#343
We should add a compile time framework (Dagger2?) to make it easier to mock dependencies of a class.
Kotlin based wrapper APIs
#63
Therefore we also could create a nice DSL.
But in essence a basic version for the XdmNode-Transaction layer for instance would involve infix functions
trx moveTo 3 and alike, removing builders, just use default parameters...
However, I'd love to discuss this with Kotlin experts :-)
WebSockets for the REST-API to stream updates/changes into the Browser in real-time
#286
This feature could be used by visualizations in the front-end for instance.
Replace the hash function
#269
We optionally store a rolling hash of all nodes in a resource. Currently, to avoid collisions as much as possible SirixDB uses the first 128 Bits of a 256 Bit SHA256 hash. We probably can use a non-cryptographic fast(er) hash function which produces a low number of hash colissions given 64Bit unique, dense, ascending nodeKeys + values...
Making the use of Keycloak in the REST-API optional
#254
In order to make it easier to setup SirixDB with an HTTP-Server for testing we should make the use of Keycloak optional.
- all OAuth2 routes should not be available
- the Auth handler can just return the current route
- in this case use
XmlDBStoreinstead ofXmlSessionDBStoreandJsonDBStoreinstead ofJsonSessionDBStore
Refactoring according to clean code principles
#109
For instance splitting classes. Maybe also using a dependency injection framework if needed which works at compile time. For instance Dagger2...
Review REST-API built with Vert.x and Kotlin (Coroutines) as well as for authentication Keycloak
#92
A code review of one or more classes would be great, as I want to write idiomatic Kotlin code. Furthermore, I'm sure we can abstract some stuff between the CRUD-classes regarding XML and JSON resources, as they are really similar.
Add documentation and/or tutorials
#114
If you give SirixDB a try, how about writing a tutorial and/or adding missing stuff to the documentation!?
Top comments (0)