[
https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14549726#comment-14549726
]
Andy Jefferson edited comment on JDO-709 at 5/19/15 11:14 AM:
--------------------------------------------------------------
As said above, you cannot do "default null" (my comment "crapness of Java
annotation defaulting"). Maybe get those Java language spec people at Oracle to
allow it? As also said above, an option is just to have the "converter"
attribute as type Class and throw away generics, and you can then have "default
void.class".
Regarding "disableConversion" and "converter", yes it is not perfect how they
interact.
We have the following ways of handling a member (or key/value/element) :
* default JDO implementation (internal) handling (what people get with JDO 3.1
or earlier)
* PMF default converter for the type
* optional class-level default converter for the type
* optional member/element/key/value converter for the type
One way we could interpret it all
1. converter not specified, disableConversion = false -> use class-level
converter if available, else use PMF converter if available, otherwise fallback
to default implementation handling.
2. converter not specified, disableConversion = true -> use default
implementation handling
3. converter specified, disableConversion = false -> use converter
4. converter specified, disableConversion = true -> use default implementation
handling
Better ideas?
was (Author: andy):
As said above, you cannot do "default null" (my comment "crapness of Java
annotation defaulting"). Maybe get those Java language spec people at Oracle to
allow it?
Regarding "disableConversion" and "converter", yes it is not perfect how they
interact.
We have the following ways of handling a member (or key/value/element) :
* default JDO implementation (internal) handling (what people get with JDO 3.1
or earlier)
* PMF default converter for the type
* optional class-level default converter for the type
* optional member/element/key/value converter for the type
One way we could interpret it all
1. converter not specified, disableConversion = false -> use class-level
converter if available, else use PMF converter if available, otherwise fallback
to default implementation handling.
2. converter not specified, disableConversion = true -> use default
implementation handling
3. converter specified, disableConversion = false -> use converter
4. converter specified, disableConversion = true -> use default implementation
handling
Better ideas?
> Standardize field/property converters
> -------------------------------------
>
> Key: JDO-709
> URL: https://issues.apache.org/jira/browse/JDO-709
> Project: JDO
> Issue Type: New Feature
> Components: api
> Reporter: Matthew T. Adams
> Assignee: Matthew T. Adams
> Priority: Minor
> Labels: converstion, converter, jdo, type, type-converter
> Fix For: JDO 3.2
>
> Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch
>
>
> This request is to standardize a user's ability to specify conversions of
> fields or properties of persistence-capable classes. Currently, this is left
> to vendor extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)