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
JohannesLichtenberger posted on
Sep 26, 2019
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
JohannesLichtenberger posted on
May 19, 2020
Similar to the Python and TypeScript Client we should provide a Kotlin Client.
Create Java9 and above module-infos. #60
JohannesLichtenberger posted on
Dec 29, 2018
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
JohannesLichtenberger posted on
Jul 15, 2020
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
JohannesLichtenberger posted on
Jul 29, 2020
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
JohannesLichtenberger posted on
Oct 03, 2020
We should add a compile time framework (Dagger2?) to make it easier to mock dependencies of a class.
Kotlin based wrapper APIs #63
JohannesLichtenberger posted on
Dec 30, 2018
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
JohannesLichtenberger posted on
Jul 15, 2020
This feature could be used by visualizations in the front-end for instance.
Replace the hash function #269
JohannesLichtenberger posted on
Jun 04, 2020
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
JohannesLichtenberger posted on
May 21, 2020
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 ofXmlSessionDBStore
andJsonDBStore
instead ofJsonSessionDBStore
Refactoring according to clean code principles #109
JohannesLichtenberger posted on
Oct 03, 2019
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
JohannesLichtenberger posted on
Sep 27, 2019
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
JohannesLichtenberger posted on
Oct 06, 2019
If you give SirixDB a try, how about writing a tutorial and/or adding missing stuff to the documentation!?
暂无评论内容