>>>> It's a clusterfuck, sorry about that. We are all
>>>> 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.
>>>> 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 validator verifies that the column/tables used in the mappings
Thus we take the class and property, column and table names, put them
through NamingStrategy to see what physical name they will transform to
when you use the mappings at runtime.
>> Looking in fisheye this change were done almost 4 years
>> 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.
ok - but
this means that our validator would need to use the
namingstrategy differently pre-3.5 and post-3.5. Just need's to know that ;)