DEV Community

Cover image for Contribute to An Evolutionary Database System during #Hacktoberfest (technology stack: Java, Kotlin, Vert.x)
Johannes Lichtenberger for SirixDB

Posted on

Contribute to An Evolutionary Database System during #Hacktoberfest (technology stack: Java, Kotlin, Vert.x)

👾 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.

Alt Text

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.

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 :-)

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 XmlDBStore instead of XmlSessionDBStore and JsonDBStore instead of JsonSessionDBStore

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)