Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.0 M2
    • Fix Version/s: 1.0 M3
    • Component/s: Repository
    • Labels:
      None
    • Environment:
      windows 7, Java 6

      Description

      I would like Spring Data to support inheritance in order to persist domain classes of the same super type (interface or abstract class) to the same collection. Upon querying, I would expect spring data to materialize the correct concrete implementation.

      At a minimum, it would be nice to see the Document "type" stored along with the object. Even better might be to support discriminators via @DiscriminatorColumn/@DiscriminatorValue annotations

        Activity

        Hide
        Timothy Dennison added a comment -

        Interestingly enough, I see that the morphia project includes the class name of the class annotated with @Entity by default. See @Entity.

        Show
        Timothy Dennison added a comment - Interestingly enough, I see that the morphia project includes the class name of the class annotated with @Entity by default. See @Entity .
        Hide
        Jon Brisbin added a comment -

        This wouldn't fit all circumstances, though. What if I wanted to reconstitute this object in a Node.js application? The value of "_class" doesn't mean anything to me in that context.

        If the problem is needing to know which subclass to instantiate for a given document, I'm not sure baking that information into the value document is the way to go for all cases. I'd hate to have to write a blog post that explains how my earlier blog post about the cross-platform nature of the library being an advantage is obsolete now and when you save a document using the Java language Mongo support, you need to load that document with the Java language Mongo support.

        I implemented this feature in Riak using headers. I store the Java class name in a metadata header. Too bad MongoDB doesn't have the concept of metadata headers like Riak does, as that would be a perfect place for meta information about the document being stored.

        Show
        Jon Brisbin added a comment - This wouldn't fit all circumstances, though. What if I wanted to reconstitute this object in a Node.js application? The value of "_class" doesn't mean anything to me in that context. If the problem is needing to know which subclass to instantiate for a given document, I'm not sure baking that information into the value document is the way to go for all cases. I'd hate to have to write a blog post that explains how my earlier blog post about the cross-platform nature of the library being an advantage is obsolete now and when you save a document using the Java language Mongo support, you need to load that document with the Java language Mongo support. I implemented this feature in Riak using headers. I store the Java class name in a metadata header. Too bad MongoDB doesn't have the concept of metadata headers like Riak does, as that would be a perfect place for meta information about the document being stored.
        Hide
        Oliver Gierke added a comment -

        Fix is up. We now add a type discriminator field to the top-level document which gets considered whenever you're querying for a supertype of it or the type itself. It's still possible to query for an entirely different type though. The discriminator field should be regarded as type hint to clients reading the documents. We will add some intermediate mapping layer (see DATAMONGO-63) to allow adapting existing databases using other type discriminator keys and values.

        On the repository side we still require the managed root object to carry the id property due to some internals. I've covered that issue in DATAMONGO-131. Should be easy to solve.

        Show
        Oliver Gierke added a comment - Fix is up. We now add a type discriminator field to the top-level document which gets considered whenever you're querying for a supertype of it or the type itself. It's still possible to query for an entirely different type though. The discriminator field should be regarded as type hint to clients reading the documents. We will add some intermediate mapping layer (see DATAMONGO-63 ) to allow adapting existing databases using other type discriminator keys and values. On the repository side we still require the managed root object to carry the id property due to some internals. I've covered that issue in DATAMONGO-131 . Should be easy to solve.

          People

          • Assignee:
            Oliver Gierke
            Reporter:
            Timothy Dennison
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0d
              0d
              Logged:
              Time Spent - 0.25d
              0.25d