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