If you do JSON, it'd be mostly like MongoDB..then ...
# server
k
If you do JSON, it'd be mostly like MongoDB..then you'd have to look at supporting something like their query language which is relatively complicated.
👍 1
j
I'm using Brackit(.org) as the XQuery compiler, it already has some basic query functionality for JSON built in. I'm not an XQuery expert, but I think it would also be a much better fit instead of all the proprietary stuff all the NoSQL databases now are implementing. Just extending the XDM: http://wwwlgis.informatik.uni-kl.de/cms/fileadmin/publications/2013/Dissertation-Baechle.pdf. Their whole research was guided by Theo Haerdter. He invented the ACID paradigm for transactions. I've extended Brackit with temporal stuff as for instance the navigation XPath axis to select a node in several revisions (future::, past::, next::, previous::, first::, last::, all-time:: -- maybe I'm wrong with some names, it's just what I remember without looking in the README ;-) Also opening resources in different revisions and so on. What's currently missing are index rewrite rules. But that said those axis should work out of the box with JSON resources, also opening the resources... what's maybe not needed are the usual XPath axis which are replaced by primitives. I think basic JSON support in several layers should be done within a couple of weeks.
Furthermore, I would love to explore how to best implement horizontal scaling... most probably with at first replicating each resource at least twice and Vert.x or directly via an Ignite cache + transaction and after that look into partitioning. But that said I have so many ideas as for instance encrypting each page fragment as in ZFS in our simple byte handler pipeline, finish work on database-wide transactions encapsulating resource-transactions, tuning the internal trie-structure and further compaction of the stored nodes on disk.