Results 1 to 6 of 6
  1. #1
    MichelF is offline Member
    Join Date
    Jun 2014
    Posts
    3
    Rep Power
    0

    Default Why shouldn't AttributeConverters be used for identifiers?

    The documentation states that you should not use an AttributeConvertor on an entity identifier, because that is not portable. The "Pro JPA 2" book adds that this shouldn't be done because this "would arguably be a bad idea".

    My question is: "why?" But that is perhaps a little broad.

    Let's assume that the converter performs a non-defect, completely reversible operation. There are two concerns at stake. The first concern is to manage entities, their state and relations. The second concern is to store or retrieve these values in some kind of back-end, probably a RDBMS. If there is a strict separation of these concerns in the JPA provider, there is no reason that an identifier should be treated differently than any other attribute. Mappings, relations and bookkeeping should be in the attribute-value domain, storing them translates between the attribute-value and the RDBMS-value domains. In my opinion, these should be separate.

    Is there an architectural reason why the limitation exists?

    If not: is this limitation then actually a result of vendor specific implementations and when is that going to be fixed?

    For now I will have to settle with a non-portable solution that does a conversion of a primary key(see Context). While that works, I'd rather see a either good discussion about or a proper solution to this limit.

    Thanks in advance!

    Context
    The database we're working on use UNIQUEIDENTIFIER that defaults to NEWID() in SQL-Server and RAW(16) that defaults to SYS_GUID() in Oracle. But we also generate them in code if needed. The Java type used is UUID. JDBC hasn't got standardized support for UUIDs. SQL Server uses the GUID spec, while Oracle uses the RFC-4122. Both on the byte[] level as on the String level these databases give incompatible results, which calls for a conversion. That currently cannot be done with the pure JPA API and the vendor specific solutions also discourage the use of converters for identifiers. As we want to replace our current abstraction layer with somewhat more standard (and without loosing our customers), that is a little awkward.

  2. #2
    gimbal2 is offline Just a guy
    Join Date
    Jun 2013
    Location
    Netherlands
    Posts
    4,354
    Rep Power
    6

    Default Re: Why shouldn't AttributeConverters be used for identifiers?

    I turn your situation around.

    "The documentation states that you should not use an AttributeConvertor on an entity identifier, because that is not portable." -> Valid reasoning, great.

    Now I ask you a question: does that statement apply to you?

    My answer based on your problem description would be: no. Because you -have- a non-portable situation in the form of your UUID problem. And thus using a non-portable solution is just fine, as long as it actually works of course. Doing this would mean that you can't move your application to say MySQL. Who cares? You clearly have in your scope that your application works on SQLServer and Oracle so a solution that works on those two DBMS systems is fine.

    In my opinion of course, and I have to admit up front that even though I've used JPA/Hibernate for years, this entire problem is way out of my league and thus there is a risk I'm blabbing senseless things.
    "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis

  3. #3
    MichelF is offline Member
    Join Date
    Jun 2014
    Posts
    3
    Rep Power
    0

    Default Re: Why shouldn't AttributeConverters be used for identifiers?

    Gimbal2: True: the situation I describe is not portable. And hopefully it can be solved without the RDBMS or vendor-specific solution permeating into our entities.

    But my question is perhaps a little more philosophical: why the distinction between identifiers and non-identifiers?

    In our ancient abstraction layer (that has other issues), we already clearly separate between what is in memory (application domain) and how we exchange that information with the database (prepared values, result set values). And these domains have nothing in common, except the attribute names.

  4. #4
    gimbal2 is offline Just a guy
    Join Date
    Jun 2013
    Location
    Netherlands
    Posts
    4,354
    Rep Power
    6

    Default Re: Why shouldn't AttributeConverters be used for identifiers?

    I have to clarify a bit here just to be sure we're on the same page: I assume that an identifier in this context is generally what you mark with @Id; as in that which makes a record unique (often the primary key or composed primary key, but not necessarily). And so a non-identifier is any other entity property.

    I can venture a guess that the distinction is made simply because the identifier is already handled very specifically and separated from the other attributes because there is a high chance they're automatically generated in "some" way, where "some" is very different from DBMS to DBMS and application to application. The persistence provider needs to perform very hairy underwater logic just to be able to deal with those, so any interference you do in that area might lead to unexpected results. I've seen my fair share of those in the time I've worked with Hibernate. All of it was my fault in the end, but what it showed me is that this is very complicated and fragile technology that is designed for the general case and not the incredibly specific case you're posing here (involving even non-portable DBMS-specific data types as far as I understand it).
    "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis

  5. #5
    MichelF is offline Member
    Join Date
    Jun 2014
    Posts
    3
    Rep Power
    0

    Default Re: Why shouldn't AttributeConverters be used for identifiers?

    Quote Originally Posted by gimbal2 View Post
    I have to clarify a bit here just to be sure we're on the same page: I assume that an identifier in this context is generally what you mark with @Id; as in that which makes a record unique (often the primary key or composed primary key, but not necessarily). And so a non-identifier is any other entity property.
    Correct!
    Quote Originally Posted by gimbal2 View Post
    I can venture a guess that the distinction is made simply because the identifier is already handled very specifically and separated from the other attributes because there is a high chance they're automatically generated in "some" way, where "some" is very different from DBMS to DBMS and application to application. The persistence provider needs to perform very hairy underwater logic just to be able to deal with those, so any interference you do in that area might lead to unexpected results. I've seen my fair share of those in the time I've worked with Hibernate. All of it was my fault in the end, but what it showed me is that this is very complicated and fragile technology that is designed for the general case and not the incredibly specific case you're posing here (involving even non-portable DBMS-specific data types as far as I understand it).
    When using Java, it doesn't matter if your CPU actually supports longs and whether it stores them little-endian or big-endian. The JVM abstracts that away for you. You can do all the hairy handling on longs that you want, but how they're actually dealt with on the hardware level is irrelevant.

    The AttributeConverter abstracts the native database type away for you (1). It should also for all but the JDBC code of your provider. In when it does, it should do it for all attributes.

    (1) That is even true if the semantic meaning of a type in the database changes. If you translate a Boolean to an integer, JQL will translate "WHERE NOT attribute" literally. But if the "attribute" column is an integer, "WHERE NOT attribute" will trigger an exception. However, in the case of primary keys, we always have a non-Boolean type with clearly defined equal semantics (or you have another problem on your hands).

  6. #6
    gimbal2 is offline Just a guy
    Join Date
    Jun 2013
    Location
    Netherlands
    Posts
    4,354
    Rep Power
    6

    Default Re: Why shouldn't AttributeConverters be used for identifiers?

    I don't understand where that bit about a long is coming from, what kind of relevance that has to this thread or what that has to do with the OS. I can only assume you misunderstood me. No matter, I think you and I have hit a dead end here. There really isn't anything I can say or do that adds any kind of value to the discussion or the problem domain. Sorry.
    "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis

Similar Threads

  1. Uniform renaming of identifiers
    By Fadly Massere in forum New To Java
    Replies: 2
    Last Post: 04-16-2014, 01:06 PM
  2. NumberFormatException- shouldn't be happening?
    By RoKr93 in forum New To Java
    Replies: 5
    Last Post: 07-04-2013, 02:17 AM
  3. This shouldn't be too hard.
    By MR bruto in forum New To Java
    Replies: 4
    Last Post: 05-10-2013, 06:20 PM
  4. Find all identifiers in a java file
    By fam2315 in forum New To Java
    Replies: 5
    Last Post: 10-28-2012, 03:12 AM
  5. valid java identifiers
    By kulangotski in forum New To Java
    Replies: 7
    Last Post: 01-09-2011, 10:47 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •