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...
Dne pondělí 14. září 2015 21:46:36 UTC+2 Curtis Stanford napsal(a):
>
> Thank you for the great response. I will try the save() approach. It would
> probably perform better than setting the map again. I was hoping there was
> a way to do this using just the graph API but this will do for now.
>
> A small issue with your code: the Vertex class doesn't have a getRecord()
> method. You have to cast it to an OrientVertex.
>
> Curtis
>
> On Monday, September 14, 2015 at 12:21:12 PM UTC-6, Jan Plaček wrote:
>>
>> "Going into the orient-specific API and getting the underlying record
>> works but changing the map on the record doesn't save the changes at
>> transaction's end."
>>
>> That is interesting, at first I thought that the returned map itself
>> probably isn't "managed", that it is a copy of some internal LINKMAP
>> strucutre ... this way it would make sense that changes are not propagated
>> and re-seting the field with updated map is necessary.
>> However you will actually obtain instance of ORecordLazyMap:
>>
>> Lazy implementation of LinkedHashMap. It's bound to a source ORecord
>> object to keep track of changes. This avoid to call the makeDirty() by hand
>> when the map is changed.
>>
>> So I tested this and it's all true, the document is dirty, but changes
>> are not commited. Why?
>>
>> WHEN WORKING WITH DOCUMENT API YOU HAVE TO EXPLICITELY CALL
>> ODocument.save()
>>
>> Here is an example:
>>
>> Vertex v = graph.getVertex("#x:y");
>> Map<String, ORecord> map = v.getRecord().field("linkMap", OType.LINKMAP);
>> map.remove("v1");
>> v.getRecord().save();
>> graph.shutdown(); // or graph.commit();
>>
>> UPDATE:
>> I updated the example so that map entry is a type of ORecord intead of
>> Vertex (ODocument is also an option in our case)
>> Even though the example worked with Vertex, it will produce exception
>> later, when accessing that entry.
>>
>
--
---
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.
