The documentation
<http://www.orientechnologies.com/docs/last/orientdb.wiki/Fetching-Strategies.html>
actually states:
NOTE: fetching Object will mean their presence inside your domain entities.
> So if you load an object using fetchplan *:0 all LINK type references won't
> be loaded.
This appears to be be untrue for the REST API, which not only fetches them,
but denormalizes by embedding linked entities (?)
The binary protocol and PHP client seems to work differently - here, the
entities are not embedded, but fetch plan doesn't seem to be supported at
all?
$client->select("select from Person WHERE friend = #10:1", '*:1')
Results in OrientDBWrongParamsException: "Fetch is useless with
COMMAND_QUERY"
I know the PHP client is incomplete - is fetch plan otherwise supported by
the binary protocol or not? It appears in the documentation as a top-level
feature...
On Wednesday, December 3, 2014 12:59:58 PM UTC+1, mindplay.dk wrote:
>
> I was somewhat surprised at the format of the REST API response, when
> executing a query along the lines of:
>
> SELECT FROM Person WHERE first_name = 'Rasmus'
>
> What I get, is the following:
>
> array(1) {
> 'result' =>
> array(1) {
> [0] =>
> array(7) {
> '@type' =>
> string(1) "d"
> '@rid' =>
> string(5) "#10:0"
> '@version' =>
> int(2)
> '@class' =>
> string(6) "Person"
> 'last_name' =>
> string(7) "Schultz"
> 'first_name' =>
> string(6) "Rasmus"
> 'friend' =>
> array(6) {
> '@type' =>
> string(1) "d"
> '@rid' =>
> string(5) "#10:1"
> '@version' =>
> int(1)
> '@class' =>
> string(6) "Person"
> 'last_name' =>
> string(10) "Thinggaard"
> 'first_name' =>
> string(2) "Bo"
> }
> }
> }
> }
>
> Although this record is linked (not embedded), it appears embedded in the
> result.
>
> What I was expecting, was something more along the lines of this:
>
> array(1) {
> 'result' =>
> array(1) {
> [0] =>
> array(7) {
> '@type' =>
> string(1) "d"
> '@rid' =>
> string(5) "#10:0"
> '@version' =>
> int(2)
> '@class' =>
> string(6) "Person"
> 'last_name' =>
> string(7) "Schultz"
> 'first_name' =>
> string(6) "Rasmus"
> 'friend' =>
> string(5) "#10:1"
> }
> [1] =>
> array(6) {
> '@type' =>
> string(1) "d"
> '@rid' =>
> string(5) "#10:1"
> '@version' =>
> int(1)
> '@class' =>
> string(6) "Person"
> 'last_name' =>
> string(10) "Thinggaard"
> 'first_name' =>
> string(2) "Bo"
> }
> }
> }
>
> The fact that a related record appears as embedded in a parent record,
> rather than as a reference, is what surprises me.
>
> Suppose multiple Person documents have the same friend reference - you
> would get multiple copies of the same record in the response then?
>
> Isn't that a form of denormalization?
>
> And what about circular references? If you use the default fetch strategy,
> can you send the server into a circular tail spin?
>
> I would expect embedded documents to appear as embedded in their parent
> document, because they're value objects, not entities, right?
>
> But links? These are references to other entities. Only the reference
> itself (the key) is actually part of the parent aggregate - the entity
> itself is not. Why should it appear inside the entity as though it were an
> embedded value object?
>
>
--
---
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.
