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@ On Wednesday, 1 April 2015 07:16:41 UTC-3, MrFT wrote: > > > 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 <http://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: >> >> 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.) >> >> >> >> -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
