Contribute to An Evolutionary Database System during #Hacktoberfest (technology stack: Java, Kotlin, Vert.x)
Johannes Lichtenberger
Posted on October 4, 2020
👾 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!?
Posted on October 4, 2020
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.
Related
October 4, 2020