[jira] Created: (OPENJPA-1683) Why string encoding of OpenJPA Identity instances for LongId differes from other built-in identity types?

["Pinaki Poddar (JIRA)" <ji...@apache.org>]

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.