Closed idmitrievsky closed 7 years ago
Thanks for the question. The behavior change is not dependent on the path, but on the structure of the data being queried. When Odin indexes data it finds all collections and flattens them into tuples. So the data: {:foo {:bar 42}}
gets indexed as:
[[] :foo [:foo]]
[[:foo] :bar 42]
The vectors []
and [:foo]
have metadata on them of :path true
this signifies that these are paths. It is a bit counter intuitive, so I should figure out a way to clarify it in the docs/code. But collections are referenced by path. This allows for the engine to keep these different paths through the data separate. Imagine the following data:
{:bill {:total 400}
:jane {:total 400}}
If we referred to the values as {:total 400}
we would have no way, based purely on the value, to tell if we were talking about Bill or Jane's account.
Thanks for the example!
I feel like I need some time to check out the paper you reference in the README because it still doesn't click for me why
{:bill {:total 400}
:jane {:total 400}}
is indexed by Odin as (if I understand correctly)
[[] :bill [:bill]]
[[:bill] :total 400]
[[] :jane [:jane]]
[[:jane] :total 400]
and not
[[] :bill {:total 400}]
[[:bill] :total 400]
[[] :jane {:total 400}]
[[:jane] :total 400]
So this approach would work fine if we only wanted to move "down" through the tree of data. However if we move down, then back up, we would loose some context. This is to say, {:total 400}
provides no information as to where this data exists in the tree of our input data. Worse yet, two accounts have this exact same data, so the engine would probably think they are the same.
However, if we refer to the account via a get-in
path, we have [:fred]
that not only tells us how we got here, but also how to move "up" by simply popping off one element in the vector.
Thank you for the explanation!
Hello,
I have a question about the accounts example.
So the output is not the same as in the README, but that is not the question.
In general I thought that for the query
the following holds for any data:
for all tuples of
?path, ?key, ?val
returned by the query.And it seems to be the case for non-empty paths:
but not for the empty ones:
I was expecting to get this because with an empty path we operate on the outer
data
map:Can you explain the intuition behind this behaviour, please?