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@: > > 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.
