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/... >>>> >> 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 >>