[jira] [Comment Edited] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17359994#comment-17359994 ] Andy Jefferson edited comment on JDO-709 at 6/9/21, 11:44 AM: -- The other use of the "attributeName" was when wanting to define a converter for the key/value of a Map (attributeName="key", or attributeName="value"), or when we have a Collection of some non-persistable element and wanting to define a converter for the element type. That could be of use, and DataNucleus has the code for it ... but it *would* require the Converts annotation if the user is providing "key" *and* "value" converters. So we could add the attributeName to the Convert annotation just for those 3 specific cases, but ignore the embedded field converter override. Whether it's worth the effort at this point is arguable, not so highly used was (Author: andy): The other use of the "attributeName" was when wanting to define a converter for the key/value of a Map (attributeName="key", or attributeName="value"), or when we have a Collection of some non-persistable element and wanting to define a converter for the element type. That could be of use, and DataNucleus has the code for it ... but it does not require the Converts annotation though. So we could add the attributeName to the Convert annotation just for those 3 specific cases, but ignore the embedded field converter override. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >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 (v8.3.4#803005)
[jira] [Comment Edited] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17337682#comment-17337682 ] Craig L Russell edited comment on JDO-709 at 5/12/21, 9:30 PM: --- Here are proposed specification updates. 5.4.1 Application identity No change unless we decide to allow converted fields to be primary key fields. 6.3 Second Class Objects Second Class Objects are instances of: - immutable system classes (java.lang.Integer, java.lang.String, etc.), - JDO implementation subclasses of mutable system classes that implement the functionality of their system class (java.util.Date, java.util.HashSet, etc.) - user-defined non-persistence-capable classes that use a user-defined converter (converted classes) - persistence- capable classes. Second Class Objects of mutable system classes and persistence-capable classes track changes made to them, and notify their owning FCO that they have changed. SCO fields of converted classes are declared using metadata, either in the associated jdo metadata file or via annotation. 6.4 Field types of pc classes 6.4.3 Persistent fields Converted Types JDO implementations must support fields of user-defined types that have an associated converter that defines conversion of values between the user-defined type and a supported database type. Fields declared to have a converter default to persistent, regardless of whether the converter is declared in annotations or the xml metadata file. 14.6 Query Interface void declareParameters (String parameters); Bind the parameter statements to the query instance. This method defines the parameter types and names that will be used by a subsequent execute method. Converted types may be used as parameters. 14.6.2 Query Filter Specification Rules for constructing valid expressions follow the Java language, except for these differences: • Equality and ordering comparisons between primitives, instances of converted classes, and instances of wrapper classes are valid. • Equality and ordering comparisons between fields containing instances of converted classes use the converted values for comparison. • Arithmetic operations (addition, subtraction, multiplication, division, or modulo) on fields use the converted values as the expression terms. Methods apply to converted types. was (Author: clr): Here are proposed specification updates. 5.4.1 Application identity No change unless we decide to allow converted fields to be primary key fields. 6.3 Second Class Objects Second Class Objects are instances of: - immutable system classes (java.lang.Integer, java.lang.String, etc.), - JDO implementation subclasses of mutable system classes that implement the functionality of their system class (java.util.Date, java.util.HashSet, etc.) - user-defined non-persistence-capable classes that use a user-defined converter (converted classes) - persistence- capable classes. Second Class Objects of mutable system classes, converted classes, and persistence-capable classes track changes made to them, and notify their owning FCO that they have changed. SCO fields of converted classes are declared using metadata, either in the associated jdo metadata file or via annotation. 6.4 Field types of pc classes 6.4.3 Persistent fields Converted Types JDO implementations must support fields of user-defined types that have an associated converter that defines conversion of values between the user-defined type and a supported database type. 14.6 Query Interface void declareParameters (String parameters); Bind the parameter statements to the query instance. This method defines the parameter types and names that will be used by a subsequent execute method. Converted types may be used as parameters. 14.6.2 Query Filter Specification Rules for constructing valid expressions follow the Java language, except for these differences: • Equality and ordering comparisons between primitives, instances of converted classes, and instances of wrapper classes are valid. • Equality and ordering comparisons between instances of converted classes use the converted values for comparison. • Arithmetic operations (addition, subtraction, multiplication, division, or modulo) on fields use the converted values as the expression terms. Methods apply to converted types. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch,
[jira] [Comment Edited] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14565104#comment-14565104 ] Andy Jefferson edited comment on JDO-709 at 5/29/15 5:48 PM: - +1 on the rename of the default annotation converter. Yes the boolean means what you say (and no problem with the name you proposed), the only thing is that in an annotation it needs a default value. If we put false then that implies it will need a provided converter. If we put true then that implies it will have to be set to false if the user wants to specify a converter of their own (as well as specifying the converter attribute). An alternate would be to NOT have as a boolean (like we did for all other annotations), and instead have as String ... then the default would be , and your rules would work. was (Author: andy): +1 on the rename of the default annotation converter. Yes the boolean means what you say (and no problem with the name you proposed), the only thing is that in an annotation it needs a default value. If we put false then that implies it will need a provided converter. If we put true then that implies it will have to be set to false. An alternate would be to NOT have as a boolean (like we did for all other annotations), and instead have as String ... then the default would be , and your rules would work. 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)
[jira] [Comment Edited] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14549726#comment-14549726 ] Andy Jefferson edited comment on JDO-709 at 5/19/15 10:53 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? 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? If you specify converter and disableConversion then the disable is ignored. It means the exact same as the XML variant that was already discussed. i.e 1. No converter, no disable - use PMF converter if one is provided 2. No converter, with disable - use no converter 3. Converter specified - use converter PMF level means the same as your PMF converter 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)
[jira] [Comment Edited] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
