Hm maybe, LINK MAP should actually be a type of Map<String, OIdentifiable>
instead of Map<String, ORecord> that would solve the problems I quess?
About the multi-model: When you're working with a Graph database, you
should not think about some LINK MAP, it's not part of the Graph :)
Graph has verticies, edges, properties (of simple data type) end of story.
You should model your domain with those.
If you need LINK MAP for performance reasons than you're leaving Graph API
and it's actually cool that you have an option to do so.
Why is it cool? Because If you think about how any data is stored, than you
will realize that all data is stored the same way and you only use
different level of abstraction to access them.
The allowed amount of abstraction is limited by performance. So why should
you be limited by API as well?
>From my point of view the OrientDB is just not hiding from you that Graph
DB is just an abstraction over some Document DB and Document DB is an
abstraction over some Key-Value DB and so on...
I quite like that concept so far, but there aren't many alternatives so I
am not making any conclusions.
Dne pondělí 14. září 2015 23:46:43 UTC+2 Curtis Stanford napsal(a):
>
> Good points. I would like to be able to do something like:
>
> Map<String, ODocument> map = vertex.getProperty("map"); // returns a map,
> not an iterable
> map.remove("a");
> map.put("b", new ODocument());
> // change is saved when transaction is committed.
>
> Also, since every vertex has an ID, just like an ODocument, I don't see
> the problem with just adding the identifier to the map whether it's a
> vertex or a document. Every vertex and edge (heavyweight) is a document
> underneath anyway.
>
> This is one of my least favourite aspects of OrientDB. The whole
> multi-model thing is great in theory but there are too many ways of one
> model bleeding into another. When I'm working with a graph database, I
> don't want to have to deal with the document part of it.
>
> Anyway, thanks again for your help.
>
> On Monday, September 14, 2015 at 3:22:21 PM UTC-6, Jan Plaček wrote:
>>
>> Yea I fixed the example once again.
>> I think that sticking with Graph API, would be quite complicated. The
>> Graph API knows only verticies, edges and properties. It does not know the
>> concept of ORecord, so it can't know the concept of LINK MAP.
>> The LINK MAP can reference any ORecord, the problem is that OrientElement
>> does not extend the ORecord, but aggregates it.
>> This means that casting ORecord to Element/Vertex/Edge is not possible.
>> (like it's possible with ODocument)
>> So we would need a new concept - ELEMENT MAP.
>> But that is actually a really complicated concept - how do you ensure
>> that ID's stored in ELEMENT MAP actually points to Element (Edge or
>> Vertex)? It would require costly integrity check.
>> Maybe fallbacking to Document API follows KISS principle better in this
>> case.
>> On the other hand I bet there will be a lot of people trying to convert
>> that Document back to Vertex (new OrientVertex(graph, record)), which
>> isn't kosher as well...
>>
>>
--
---
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.
