I guess I never considered that LINK MAP is not part of the Graph API. Good
point.
On Monday, September 14, 2015 at 5:43:49 PM UTC-6, Jan Plaček wrote:
>
> 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.
