[
https://issues.apache.org/jira/browse/OPENJPA-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dick closed OPENJPA-1683.
---------------------------------
Resolution: Fixed
Please open another issue if there is more work to be done here.
> Why string encoding of OpenJPA Identity instances for LongId differes from
> other built-in identity types?
> ---------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-1683
> URL: https://issues.apache.org/jira/browse/OPENJPA-1683
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Reporter: Pinaki Poddar
> Assignee: Pinaki Poddar
> Fix For: 2.1.0
>
>
> How the built-in classes for persistent identity value encodes as itself as a
> String is critical/significant -- because
> a) the encoded string often is decoded to extract the original value for
> instance look up
> b) for untyped persistence capable instances, the encoded string carries the
> actual class name -- and hence is important to instantiate the actual
> instance during loading from database
> Unfortunately, this important decision about encoding-decoding of identity
> value is *not* emphasized with methods such as encode()/decode() on OpenJPAId
> but encoding is done with ubiquitous Object.toString() and decoding is
> burried in code lines.
>
> While it is perhaps important to review this scheme, the immediate issue at
> hand is somewhat narrower and as follows:
> The root *abstract* class OpenJPAId has the following toString()
> implementation
> public String toString() {
> return type.getName() + "-" + getIdObject();
> }
>
> The concrete implementation such as IntId or FloatId overwrites this
> behavior as follows:
> IntId.java:
> private final int key;
> public String toString() {
> return String.valueOf(key);
> }
> FloatId.java:
> private final float key;
> public String toString() {
> return Float.toString(key);
> }
> Apart from the subtle difference (but why), they look to be following the
> same principle, i.e. just stringify the value.
> But the interesting part is LongId *does not* have a toString() method.
> Hence its toString() form is dictated by its abstract super class OpenJPAId
> which appends the class name with a dash character to the actual long value
> of the identity.
> I can not figure out the reason of this anomaly for long identifier as
> opposed to other Short/Integer or Float etc.
> The risk of simply adding a toString() to LongId that is in line with
> other id types, of course, a) breaking any existing application that may be
> assuming the previous encoding
> b) the unknown original reason behind *not* overwriting LongId.toString()
> method
> Can someone please, please answer/shed some light?
> It is critical for some direction I am pursuing to support
> generic/templated types where exact types are not determinable at
> compile/design time.
> Without an answer, I will commit the change on LongId to have a toString()
> method.
> +
> + public String toString() {
> + return String.valueOf(key);
> + }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
