System fields in documents

orientechnologies / orientdb

OrientDB is the most versatile DBMS supporting Graph, Document, Reactive, Full-Text and Geospatial models in one Multi-Model product. OrientDB can run distributed (Multi-Master), supports SQL, ACID Transactions, Full-Text indexing and Reactive Queries.

https://orientdb.dev

Apache License 2.0

4.74k stars 870 forks source link

System fields in documents #7701

Open andrii0lomakin opened 7 years ago

andrii0lomakin commented 7 years ago

Currently to express graph structure regarding documents we use fields like "in", "out" and so on. The problem with those fields that they can be accessed by users as result information which should be encapsulated inside documents can be changed by users. It is proposed to introduce the concept of system fields. Let suppose we will have fields which have names, not "in" but "@in" for example, those fields can not be accessed by conventional access methods like document.field(). So queries which are used to update and create documents or vertexes like "update/upsert" and so on will not be able to access and modify and damage content of those fields. Those fields will be accessed only in special places like in "in()" function or "create edge" function. The downside of this approach, of course, is that users in their SQL queries always should use graph functions instead of plain fields. But the idea initially was that those fields had to be encapsulated.

smolinari commented 7 years ago

This is a great idea. The "inner workings" of how graph connectivity is managed by ODB should be hidden for sure.

Scott

lvca commented 7 years ago

+100, we already have similar issues about that, especially with the REST API where we shouldn't return them as properties, but as edge structure.

luigidellaquila commented 7 years ago

+100, having explicit "user level" fields for edges is not optimal for me. This said, I think we have to consider a few aspects:

backward compatibility
collisions with user level fields (eg. I can declare an @out field just because I need it, I don't like very much the idea to inhibit it for users); this means that we need two different structures (eg. two different maps in the ODocument) to keep user level and internal fields
serialization/deserialization
third party drivers that rely on the current convention...

Thanks

Luigi

andrii0lomakin commented 7 years ago

@luigidellaquila I believed that we do not allow fields with names which start from @ , do not we?

luigidellaquila commented 7 years ago

@laa in v 3.0 we allow any character for field names (even punctation, spaces and so on), the only reserved words are @rid, @class and a few more

Thanks

Luigi

smolinari commented 7 years ago

Hi Luigi,

Um, we are discussing and focusing on 3.0, which is still in beta, right? So BC shouldn't be an issue. A migration topic it might be maybe, at best.

So, I vote to do things right and hide what should have been implementation details for graph connectivity in ODB in the first place. This information was only visible in the past, because, as I recall, ODB's graph capability was built on top of its document capability. Do correct me if I am wrong.

I'd even go so far as to say any necessary indexing of edges (i.e. ins and outs) should also be hidden from userland. 😄

Scott

andrii0lomakin commented 7 years ago

One more reason to implement this issue https://github.com/orientechnologies/orientdb/issues/7826