Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <31145725.7161273700081896.JavaMail.jira@thor>
Date: Wed, 12 May 2010 17:34:41 -0400 (EDT)
From: "Pinaki Poddar (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Commented: (OPENJPA-1612) Mapping an unsupported type
In-Reply-To: <760585936.697291270502307174.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/OPENJPA-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866743#action_12866743 ] 

Pinaki Poddar commented on OPENJPA-1612:
----------------------------------------

> 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. 


> Mapping an unsupported type
> ---------------------------
>
>                 Key: OPENJPA-1612
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1612
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: kernel
>    Affects Versions: 1.2.2, 2.0.0, 2.1.0
>            Reporter: Rick Curtis
>            Assignee: Rick Curtis
>            Priority: Minor
>             Fix For: 2.1.0
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.