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