As I suspected, this does lead to denormalization - as per this example
where two Person documents reference the same friend:
array(1) {
'result' =>
array(2) {
[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"
}
}
[1] =>
array(7) {
'@type' =>
string(1) "d"
'@rid' =>
string(5) "#10:2"
'@version' =>
int(1)
'@class' =>
string(6) "Person"
'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"
}
'last_name' =>
string(4) "Tuna"
'first_name' =>
string(7) "Charlie"
}
}
}
Is this "by design"?
Because it mostly defeats the purpose of fetch strategies, in my opinion.
With a relational database, we're forced to denormalize, if we want related
data in a single roundtrip. Say, a list of customers with country names.
We're forced to join customers with countries, which means that, for 100
customers in 3 countries, the server needs to encode and send the same 3
country names a total 100 times, and the client then needs to sort through
and discard the duplicate data while mapping the results to objects.
With a document database, this should not be necessary - we should not need
to denormalize, transfer, encode or decode the same entity more than once
during a single round-trip.
Am I missing something obvious or is there something important I haven't
understood yet?
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.