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
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.)