Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Not a Problem
    • Affects Version/s: 1.2.2, 2.0.0, 2.1.0
    • Fix Version/s: 2.1.0
    • Component/s: kernel
    • Labels:
      None

      Description

      As discussed on the dev mailing list [1]...

      I found that the following mapping:

      @Entity
      public class AnnoTest1

      { @ManyToOne Object o; ... }

      This results in a warning message [2], but it is allowed. This JIRA will be used to detect this condition and fail fast.

      [1] http://openjpa.markmail.org/thread/6yphicehgclyobag
      [2] 297 TestConv WARN [main] openjpa.MetaData - OpenJPA cannot map field "test.AnnoTest1.o" efficiently. It is of an unsupported type. The field value will be serialized to a BLOB by default.

        Activity

        Hide
        Rick Curtis added a comment -
        Show
        Rick Curtis added a comment -
        Hide
        Rick Curtis added a comment -

        Reverted previous commit. Closing this JIRA as a non-issue.

        Show
        Rick Curtis added a comment - Reverted previous commit. Closing this JIRA as a non-issue.
        Hide
        Pinaki Poddar added a comment -

        > Prior to this commit, OpenJPA took the liberty to serialize B to save it to the DB.

        OpenJPA manual clearly describes how it treats untyped relations. This feature is to support relations that are partially known at declaration time.
        This feature leads to OpenJPA's capability to work with generic types in a graceful way. So it is not about taking liberty at random, but taking liberty to be not confined by a specification.

        The right question in my view is what can OpenJPA do with the following domain model that is most useful to the developer/user?

        // A persistent type with a relation whose exact type is unknown at declaration.
        @Entity
        public class A

        { @OneToOne Object relation; }

        @Entity
        public class B {
        }

        But at runtime, the user can supply a persistent type for that relation

        A a = new A();
        a.setRelation(new B());

        Given zero-commitment from the user on type of relation, this will create a serialized B is database.
        But in the domain model, if the user had added OpenJPA extension
        @Entity
        public class A

        { @OneToOne @Type(Entity.class) Object relation; }

        then OpenJPA be able to save the relation as structured data – that is a powerful and useful feature. And OpenJPA was capable of doing exactly that.

        So to me, the positive or forward approach is to say how we can make generic type support work than to say what we do not allow because a spec says so.
        Hence, when we serialize something as a blob because we do not know any better, we should warn with a suggestion message that though we are now
        serializing the relation but we can as well store that untyped relation if the user had clarified its type to some further.

        Show
        Pinaki Poddar added a comment - > Prior to this commit, OpenJPA took the liberty to serialize B to save it to the DB. OpenJPA manual clearly describes how it treats untyped relations. This feature is to support relations that are partially known at declaration time. This feature leads to OpenJPA's capability to work with generic types in a graceful way. So it is not about taking liberty at random, but taking liberty to be not confined by a specification. The right question in my view is what can OpenJPA do with the following domain model that is most useful to the developer/user? // A persistent type with a relation whose exact type is unknown at declaration. @Entity public class A { @OneToOne Object relation; } @Entity public class B { } But at runtime, the user can supply a persistent type for that relation A a = new A(); a.setRelation(new B()); Given zero-commitment from the user on type of relation, this will create a serialized B is database. But in the domain model, if the user had added OpenJPA extension @Entity public class A { @OneToOne @Type(Entity.class) Object relation; } then OpenJPA be able to save the relation as structured data – that is a powerful and useful feature. And OpenJPA was capable of doing exactly that. So to me, the positive or forward approach is to say how we can make generic type support work than to say what we do not allow because a spec says so. Hence, when we serialize something as a blob because we do not know any better, we should warn with a suggestion message that though we are now serializing the relation but we can as well store that untyped relation if the user had clarified its type to some further.
        Hide
        Rick Curtis added a comment -

        Reopening to discuss the validity of my change.

        Show
        Rick Curtis added a comment - Reopening to discuss the validity of my change.
        Hide
        Rick Curtis added a comment -

        Pinaki -

        I'll start off by saying that I'm not dead set on this commit by any means. The intent of this commit was to improve the usability of OpenJPA, but it sounds like I may have sacrificed some functionality that we used to have.

        The problem I was trying to fix is as follows:

        • Joe user has two Entities {A,B}

          and A has a @OneToOne to B.

        • Joe messes up when he specifies <class>(s) in his p.xml file and omits B.
        • Prior to this commit, OpenJPA took the liberty to serialize B to save it to the DB. Perhaps there are certain use cases where this would be okay, for the sake of the test it wasn't.

        Since javax.persistence.xTox annotations are defined by the spec, I don't think we have the liberty to define them in any way we like. My understanding is that these annotations are for Entity to Entity relationships. The code I added checks for this and fails fast.

        Show
        Rick Curtis added a comment - Pinaki - I'll start off by saying that I'm not dead set on this commit by any means. The intent of this commit was to improve the usability of OpenJPA, but it sounds like I may have sacrificed some functionality that we used to have. The problem I was trying to fix is as follows: Joe user has two Entities {A,B} and A has a @OneToOne to B. Joe messes up when he specifies <class>(s) in his p.xml file and omits B. Prior to this commit, OpenJPA took the liberty to serialize B to save it to the DB. Perhaps there are certain use cases where this would be okay, for the sake of the test it wasn't. Since javax.persistence.xTox annotations are defined by the spec, I don't think we have the liberty to define them in any way we like. My understanding is that these annotations are for Entity to Entity relationships. The code I added checks for this and fails fast.
        Hide
        Pinaki Poddar added a comment -

        Rick,
        In my view, this is not a change in the right direction.

        OpenJPA used to have a reasonably advanced support for untyped relations. These capabilities are described in [1]
        Now in the past, I had used these powerful features to demonstrate how generically typed structures can be modeled [2] in OpenJPA (that blog unfortunately has been eaten by a very powerful company and one can merely find its indirect cached references by searching for 'Persistence of Generic Graph Pinaki Poddar" .
        Recently I noticed that those powerful type system is weakened (meaning those neat generic model example does not work with OpenJPA 2.0).
        Support for generically typed domain model is a powerful construct and OpenJPA was quite capable of meeting that demand. Hence I consider OpenJPA 2.0 has regressed on that aspect.

        I have not investigated deeply, but my cursory look at the changes suggest that cause of the regression is more at the surface and can be corrected at ease.
        In view of that observation, I see this current commit as a step backward. And I hope that the original committer will consider rolling the change back.

        [1] will provide the user sufficient choices on how to persist Object o – when it is assigned to a Persistence Capable entity, or merely a Serializable at different levels of OpenJPA type support.

        [1] http://openjpa.apache.org/builds/latest/docs/manual/manual.html#type
        [2] http://www.mail-archive.com/users@openjpa.apache.org/msg01370.html

        Show
        Pinaki Poddar added a comment - Rick, In my view, this is not a change in the right direction. OpenJPA used to have a reasonably advanced support for untyped relations. These capabilities are described in [1] Now in the past, I had used these powerful features to demonstrate how generically typed structures can be modeled [2] in OpenJPA (that blog unfortunately has been eaten by a very powerful company and one can merely find its indirect cached references by searching for 'Persistence of Generic Graph Pinaki Poddar" . Recently I noticed that those powerful type system is weakened (meaning those neat generic model example does not work with OpenJPA 2.0). Support for generically typed domain model is a powerful construct and OpenJPA was quite capable of meeting that demand. Hence I consider OpenJPA 2.0 has regressed on that aspect. I have not investigated deeply, but my cursory look at the changes suggest that cause of the regression is more at the surface and can be corrected at ease. In view of that observation, I see this current commit as a step backward. And I hope that the original committer will consider rolling the change back. [1] will provide the user sufficient choices on how to persist Object o – when it is assigned to a Persistence Capable entity, or merely a Serializable at different levels of OpenJPA type support. [1] http://openjpa.apache.org/builds/latest/docs/manual/manual.html#type [2] http://www.mail-archive.com/users@openjpa.apache.org/msg01370.html
        Hide
        Rick Curtis added a comment -

        Committed revision 942871 to trunk.

        Added additional validation and a new test case.

        Show
        Rick Curtis added a comment - Committed revision 942871 to trunk. Added additional validation and a new test case.

          People

          • Assignee:
            Rick Curtis
            Reporter:
            Rick Curtis
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development