Binary protocol and list( (subquery) )

[MrFT]

This query in GratefulDeadConcerts database will in the studio, return name of the song, and a list of names (and some @rids in x_sungby that are meaningless and that I am not interested in at all).

select name, $sungbyrecord as x_sungby 

from V 

let $sungby = outE()[ @class = 'sung_by' ], 

    $sungbyrecord = list( (select in.name from $sungby) )

where name='HEY BO DIDDLEY'

But using the binary protocol, the list will simply contain #-2:xx 'virtual' record numbers, and you'd have to check the list of returned results to match these (cfr. oriento). I hope this assumption is right.

On top of that, in oriento these will only be returned, if you set the right fetchplan for those virtual records.

So you write a long query to select the names, only to find out that OrientDB is still returning only 'virtual' record-ids.

But I don't really understand why we need those virtual record numbers, and why a list that should only contain names from sungby is not simply a list with names, as asked in the query.

What good is a query language if it doesn't return what you actually ask for, a list of names, not a list of 'virtual' records?

If I would want a record I would simply do select from MyClass or select @rid from MyClass.

The fact that I explicitly select some properties implies that I am no longer interested in the whole records, no?

(I can see the reasoning behind it in an OO database, but in a document database that is also a graph database, I only see this making things harder than necessary.)

[MrFT]

Still hoping for a response and the opinion of the developers.

Trying to have a discussion about things that I find peculiar...

• Why do you think it makes sense to return subqueries as 'virtual' records? What could possibly be the use-case?
• Shouldn't a query return what the query actually queries for, isn't that what a query language is about?
  
• Should it be the responsibility of the client application or the library (for example Oriento) to puzzle the returned results together into the thing that the user actually queried for?
  
• Why doesn't it return the things in a subquery by default, meaning that currently your query only works if you also add the proper fetchplan, but by defining 'select this, that from X' in a subquery I think this already implies that this is what the user is interested in...
  
• It makes sense in the OO database paradigm, if you have a link to another record like children: [ #5:6, #5:9 ] to not load those other records by default, but if the query says select name, children.name as kids from person, then we are selecting individual fields, not records, so there should be no need for a fetchPlan. The fact that we explicitely want to know the names of the children is already part of the query.
• Furthermore, it makes the behaviour inconsistent between the studio (works even without fetchPlan), and in java or nodejs (oriento), where you don't get the results unless you specifiy the proper fetchPlan.
• When executing the query the extra information on x_sungby ( "@type": "d", "@rid": "#-2:0", "@version": 0 ) is useless, since it is not referring to something real anyway. i only see the 'real' recordids as something useful for the user (regardless of how things work internally, they are probably useful there).

[

        {

            "@type": "d",

            "@rid": "#-2:0",

            "@version": 0,

            "name": "HEY BO DIDDLEY",

            "x_sungby": [

                {

                    "@type": "d",

                    "@rid": "#-2:0",

                    "@version": 0,

                    "in": "Garcia" //why isn't this called 'name' instead of 'in'?

                }

            ],

            "@fieldTypes": "x_sungby=z"

        }

Op donderdag 26 maart 2015 02:03:39 UTC+1 schreef MrFT:

[Lvc@]

Hi,

Any result from a select with projection, provides temporary RIDs. This is because the result is always a document (json), but not the record on database, but an interpolation. If you're interesting on rid, use @rid in projection.

Lvc@

[MrFT]

Ok, then I will rephrase my question:

Is it possible that the result should in fact NOT be a document, because it is fundamentally different?

I am aware of how it works now, but I am having serious doubts about whether that has been a good design choice. This is why I am asking the questions 'What are the use-cases' etc. because if these cannot be answered, one should start to question if the way it currently works is actually something hat makes sense (to an end-user).

In my opinion something that is not a record in the database is not a document, it is a projection or an interpolation or whatever you want to call it.

Since it is not a document, it doesn't need to have a (temporary) rid, nor a version. This just doesn't make sense. And it also doesn't make sense that you won't get your whole projection unless you specify a fetchPlan.

Op donderdag 2 april 2015 04:20:34 UTC+2 schreef Lvc@:

[MrFT]

Has anyone of the developers given these questions some thought?

It would be great if your answers could help me understand some of the design choices made in OrientDB better, but I'd also like to know if maybe I made a valid point?

Op vrijdag 3 april 2015 08:39:39 UTC+2 schreef MrFT: