menu

EdgeDB

Bringing state-of-the-art database technology to the masses.

Channels
Team

How to store hierarchical document-like data?

February 24, 2020 at 9:35am

How to store hierarchical document-like data?

February 24, 2020 at 9:35am
In the docs intro it says "EdgeDB is not a document database, but inserting and querying hierarchical document-like data is trivial."
How would I insert document-like data? The docs have examples of doing this literally in EdgeQL, which is useful for learning, but what is the correct way to insert hierarchical application data from a client? (I'm using the JS client BTW)

February 24, 2020 at 5:42pm
The answer really depends on what your use case is and how your data is structured. For semi-structured "document" in NoSQL sense your best bet would be to use a json property and then rely on JSON operations to reason about the data.
If, on the other hand, your data is well-structured and normalized, then there's no way around using INSERT and UPDATE statements (or equivalent GraphQL operations). There is no magic way to normalize and "merge" an arbitrary JSON document. That said, we're working on improving the ability to express certain INSERT/UPDATE cases in EdgeQL and/or the binding APIs.
Please provide some details on your schema and the use case, it would be easier to find a good solution with examples of code.
  • reply
  • like

February 25, 2020 at 8:25am
My use-case is structured data. As long as my data matches the schema, I was hoping I would be able to just throw it at the database and have it stored. I've been working a lot with Datomic recently so I guess I got used to having a very seamless connection between database data and application data.
I guess this is what you are working on. It would be awesome to have a solution that, subject to following certain conventions in the object hierarchy, does a lot automatically.
For example if, where the schema expects a link, a sub-object is found, a nested INSERT happens, while if a string is found, this is interpreted as a UUID and a link to an existing object is created. For cases where the type of the sub-object is ambiguous, something like a __type field could be used. Ideally this would be supported in both link directions.
  • reply
  • like
Dammit I keep pressing enter and sending the message by accident :P
Given the introspection support, it strikes me that this should be possible as a layer on top of the existing client API, so I may have a go at something simple myself as a proof of concept.
If I'm missing something and I'm dreaming of something magical, I would really appreciate if you could explain briefly what the issue is. I'm guessing it is probably in tricky edge cases. It might be that an 80% solution (or hopefully a 95% solution) is still really useful.
  • reply
  • like

February 25, 2020 at 7:04pm
Given the introspection support, it strikes me that this should be possible as a layer on top of the existing client API
Yes, implementing this as an EdgeQL-generating layer in the client seems most appropriate. If we do it at the language level, it might complicate the spec a lot.
  • reply
  • like