The Road Ahead for database representations

As we finish up the conversion of blobs to JSON, I’m thinking about the details of how to take advantage of it. The two things I’m working on:

  1. create “business logic” functions for generic and dbapi layers
  2. add an extract_data() method for generic and dbapi layers

It is important to always have a generic implementation (uses standard database methods) so that any DB that doesn’t (or can’t) implement something better has an implementation.

For (1) I realized that there is no method that an addon writer could use JSON until specialized methods are added to generic and (at least) dbapi. It would be nice if there were a general generic method that also had an optimized version.

Which got me thinking about (2). I wrote a prototype such that this would work in generic and dbapi:

db.extract_data(["$.gramps_id", "$.private"], handle="12345")

But that gains very little (100 milliseconds) just to move the jsonpath to SQL. But if you change extract_data (rename it, and change format of handle argument and value slightly) then you get:

db.select(["$.gramps_id", "$.private"], ("$.handle", "=", "12345"))

This version operates identically to the above in terms of efficiency. But now it is directly translatable into other languages, like SQL. With this there is a db method that works on all database types, and can access the power of SQL (or other db engines). It doesn’t do joins or other more sophisticated expressions, and is limited to only what jsonpath supports in Python. But does give users and developers a doorway into writing faster code without waiting for someone to add “business logic” to the core codebase.

What do you think?