Skip to main content

[jpa-spec issues] [JIRA] Commented: (JPA_SPEC-73) Parameterized AttributeConverter and/or AttributeConverter metadata access

  • From: "c.beikov (JIRA)" < >
  • To:
  • Subject: [jpa-spec issues] [JIRA] Commented: (JPA_SPEC-73) Parameterized AttributeConverter and/or AttributeConverter metadata access
  • Date: Tue, 15 Apr 2014 15:29:49 +0000 (UTC)
  • Auto-submitted: auto-generated


    [ 
https://java.net/jira/browse/JPA_SPEC-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=374404#action_374404
 ] 

c.beikov commented on JPA_SPEC-73:
----------------------------------

I agree that metadata is needed but I guess it would be easier to just let 
the converter instance know about the metamodel Attribute instance or 
something simial.
You can define your own annotations that can be used for configuration 
purposes of the converter. Through the metamodel you can get your hands on 
those values.
I propose that you can either inject that instance or with java 8 default 
methods around, introduce a new default method "void 
init(javax.persistence.metamodel.Attribute)" in the AttributeConverter. 

> Parameterized AttributeConverter and/or AttributeConverter metadata access
> --------------------------------------------------------------------------
>
>                 Key: JPA_SPEC-73
>                 URL: https://java.net/jira/browse/JPA_SPEC-73
>             Project: jpa-spec
>          Issue Type: Improvement
>            Reporter: frenchc
>
> It would be good if we were able to parameterize AttributeConverter 
> instances and/or have access to property metadata within an 
> AttributeConverter. This way we are able to reuse AttributeConverter code 
> instead of building similar ones or even supply further required context 
> information. An example:
> Quite often we have to deal with ancient DB schemas, and just recently we 
> started to migrate a large Cobol application to Java. We are unable to 
> change the content of the database, and because of Cobol with have to 
> support fixed width string columns containing left padded data. A 5 digit 
> fixed width column will represent 1 as '00001' and 100 as  '00100'. Nothing 
> we can change here. Unless I am mistaken I have to create a dedicated 
> converter for every required fixed length ending up with an 
> LeadingZeroTwoDigitAttributeConverter,  
> LeadingZeroFiveDigitAttributeConverter and so on.
> Right now it seems the JPA spec does not define wether there is one 
> converter instance per persistent property or just a global one (which 
> would be OK by current spec requirements). I would propose that 
> parameterized converter instances are bound to property fields in order to 
> support parameter evaluation during JPA provider startup.
> I believe we need access to both basic attribute information and optionally 
> supplied converter attributes. The following example would assume access to 
> the leading pad char, the length attribute and wether the attribute is 
> nullable or not. (in my current project I have to store an empty string for 
> null values in the database).
>  
>   @Convert(converter = LeadingDigitAttributeConverter.class, 
> metaData="padChar=0" )
>   @Column(name = "ACOLUM", length=5, nullable = false)
> If you believe there is no need to support something like that: 
> Unfortunately we are in the middle of migrating quite a few very very old 
> applications to Java, and we can't change that stuff. And there is more to 
> come.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[jpa-spec issues] [JIRA] Commented: (JPA_SPEC-73) Parameterized AttributeConverter and/or AttributeConverter metadata access

c.beikov (JIRA) 04/15/2014

<Possible follow-up(s)>

[jpa-spec issues] [JIRA] Commented: (JPA_SPEC-73) Parameterized AttributeConverter and/or AttributeConverter metadata access

frenchc (JIRA) 04/15/2014
 
 
Close
loading
Please Confirm
Close