Announcement Announcement Module
Collapse
No announcement yet.
Spring Data Graph: Map pairs as node properties? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    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.

    Comment


    • #17
      Originally posted by MichaelHunger View Post
      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.

      Comment


      • #18
        Sorry, my bad.

        Comment


        • #19
          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...
          PHP Code:
          @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

          Comment

          Working...
          X