Emmanuel Bernard wrote:
  

On 10 août 09, at 11:31, Max Rydahl Andersen wrote:

    

It's a clusterfuck, sorry about that. We are all wrong except 
Max-the-manager. Oh the irony ;)
          

heey! :)
      

logicalColumnName is the name by which a column should be referred 
in metadata descriptors (like unique constraints, indexes etc). I 
don't think a user needs to use the logical mapping in HBM files 
(the metadata structure don't require it contrary to annotations).
Anyway, the logical name should never appear in a physical column 
name, so HbmBinder #fail.
          

http://opensource.atlassian.com/projects/hibernate/browse/HHH-4077

I've attached a patch and applied it to trunk. It probably needs a 
quick test on your side and can be retrofitted to older versions.
          

Doesn't this change the behavior radically ? ...and how should our 
validator know which sequence of calls it should use ...i hate bugs ;0)
      

No it does not because realistically, doing an implementation 
of logicalColumnName like the one in this test has no usecase.
What does the validator do exactly? I'm not clear how it should use 
the NS.
    

The Dali's validator checks that the table/column you are references 
exists. When user uses NamingStrategy the name of the table/column are 
different from default one, so we need to change this check according to 
the NamingStrategy altering. To do this we need to know exactly how 
Hibernete will do the conwersion of default/specified name to db-object 
name.
  

Looking in fisheye this change were done almost 4 years ago... 
http://fisheye.jboss.org/changelog/Hibernate?cs=8918
for http://opensource.atlassian.com/projects/hibernate/browse/ANN-176 
where it seems to be done very deliberately ?

are you sure this is a proper change ?
      

Of course, I always do things deliberately but then I dont' remember. 
In this case, I did fix the user bug by adding the 
mapping.addColumnBinding() calls. I think back in the days, I thought 
the logicalColumn should also be passed toNS.columnName. I think it is 
wrong today.
In practice, MC.logicalColumn is almost always idempotent if the 
column name is not null. That's why we have never seen any impact.

    

FTR
Hibernate Annotations uses a different naming strategy than core 
for backward compatibility reasons.
JPA defaults are not Hibernate Core defaults
http://anonsvn.jboss.org/repos/hibernate/core/trunk/annotations/src/main/java/org/hibernate/cfg/EJB3NamingStrategy.java
          

Yes, but that we will just pick up automatically since it does not 
change the sequence of calls done to the namingstrategy.

Anyway, for now we'll just focus on the JPA behavior since that is 
the most relevant for JPA Project validation at least ;)

/max
      

-- 
Best regards,

 Dmitry Geraskov              
 dgeraskov@exadel.com
 Senior Developer
 Exadel Inc