[JPA_SPEC-35] Support for more Java types Created: 06/Aug/12  Updated: 20/Mar/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: mkarg Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

JPA currently only supports few Java types to be persisted, mostly generic types, Strings and Date. Since many applications would benefit from it, support for direct persistence of java.net.URL (as VARCHAR) and java.awt.Image (as BLOB) should be added. Both are commonly used in many applications and currently produce an overhead of manually written code when to be used in JPA entities.

In addition (or as a replacement for the above), it would be great to have the possibility to map any not supported Java type to any kind of supported Java type, in analogy to the XmlAdapters used in JAXB marshall / unmarshall. This would relax the need for special support for Image and URL. As an example how this could work, please look at the following pseudo-code, which demonstrates how java.net.URL could get marshalled to a String at time of persisting it:

@Column(name = "MY_SQL_FIELD_NAME"
@JpaAdapter(UrlJpaAdapter.class)
private URL someField;
...
public class UrlJpaAdapter.class extends JpaAdapter<String, URL> {
public URL unmarshal(String v) throws MalformedURLException

{ return new URL(v); }

public String marshal(URL v)

{ return v.toString(); }

}



 Comments   
Comment by sinuhepop [ 05/Nov/12 ]

I agree. This is a very common need and must be placed in JPA standard.

But I think it will be too verbose to put always the same annotation n the same types. Maybe is better to use a TypeRegistry:

TypeRegistry registry = entityManagerFactory.getTypeRegistry();
registry.register(URL.class, new UrlJpaAdapter());

Comment by neilstockton [ 20/Mar/15 ]

Alternatively, allow JPA implementations to support as many field types as they want to, and provide method(s) on ProviderUtil that returns the types that are supported, or whether a type is supported.

JPA could also just link in to the AttributeConverter facility, and a JPA implementation could find what converters are available in the CLASSPATH (and hence has support for them). Hence if a library provider wants their types automatically supported in all JPA implementations they just provide AttributeConverters ...

Generated at Sat May 30 05:24:20 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.