Open andrii0lomakin opened 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
+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.
+100, having explicit "user level" fields for edges is not optimal for me. This said, I think we have to consider a few aspects:
@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 fieldsThanks
Luigi
@luigidellaquila I believed that we do not allow fields with names which start from @ , do not we?
@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
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
One more reason to implement this issue https://github.com/orientechnologies/orientdb/issues/7826
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.