Spring Data Graph: Map pairs as node properties?

[MichaelHunger]

Ok, that fits perfectly, I'm also off for 3 weeks.

Enjoy your vacation.

Michael

[ractive]

Thanks, I will. Enjoy yours as well.

James

[ractive]

Please see https://github.com/SpringSource/spri...a-graph/pull/8 for a first implementation of DynamicProperties.
Currently, only the "inline" properties are implemented. I'd be glad if you could have a look and tell me what you think.

What bugs me at the moment is the fact, that these dynamic properties cannot be used with detached entities, although it would be feasible. Can you see a way to do that?

[MichaelHunger]

Will look into it and merge it, what is the actual issue when changing map properties on a detached entity?

Michael

[ractive]

I did not find a way to have a ManagedPrefixedDynamicProperties container for the NodeEntities ready also in detached mode. It currently works exactly like in the AbstractNodeRelationshipFieldAccessor, where a ManagedFieldAccessorSet is created in the getValue method of the accessor.
It's currently not possible to do something like:

@NodeEntity
public class Person {
    DynamicProperties props;
}

Person p = new Person();
p.props.setProperty("foo", "bar"); 

...because the props field is null.

Bus as I mentioned in the comment of the pull request: We can live with that. :-)

[MichaelHunger]

I thought you used a Map<String,Object> for that?

DynamicProperties is nice from a semantics standpoint, but probably people will have integration issues with their domain model?

You've certainly seen that the set we managet is just an abstract set with some overriden methods.

Michael

I look into the detached-entity - null property issue again.

[ractive]

I thought you used a Map<String,Object> for that?

DynamicProperties is nice from a semantics standpoint, but probably people will have integration issues with their domain model?

You've certainly seen that the set we managet is just an abstract set with some overriden methods.

Here we decided not to use the Map interface for that. There are convenient functions asMap() and createFrom(Map<String, Object> map) to use Maps anyway.

I look into the detached-entity - null property issue again.

I'll have a look again as well. I probably just did not understand the lifecycle of a NodeEntity good enough.

[MichaelHunger]

Sorry, my bad.

[ractive]

I think it was the correct decision not to use the map interface for this, because it would not have been possible to just match "Map<String, Object>" in the FieldAccessorFactory, but only "Map" (without generic types, because of type erasure). So Map<Foo, Bar> could then have also been treated as a dynamic properties collection, which would be kind of strange.

Regarding detached mode:
Please see my last commit for another approach to use DynamicProperties in detached mode.

The previous attempt to have the entity class define it's own default implementation did not work out, because the initialization itself always set the field as dirty, so defining something like this...

@NodeEntity
public class Person {
    DynamicProperties props = new DynamicPropertiesContainer();
    ...
} 

...always resulted in an empty props container, because props has been marked as dirty - with the empty default container.

The new approach lets a FactoryAccessor define a default implementation for a field (or null). The DetachedEntityState gets such a default implementation when an entity has no persistent state and sets it as the entity's field. The setValue() method of the FieldAccessor then can decide how to persist this default implementation and the one it returns itself in getValue().

What do you think?


Best regards,
James