Hi. I would like to hear someone else's toughts on something I noticed: suppose you have a Hibernate-managed POJO that has an interface like...

----------

public void setFlag(Integer flag);

public Integer getFlag();

public Boolean isFlag();

----------

The idea here is, for whatever reason, I choose to persist a field as an Integer, but sometimes it will be more convenient for me, in my application, to retrieve it as a Boolean (say if its stored value != 0). I expect Hibernate to use setFlag and getFlag for data persistency and retrieval, but isFlag is for my use alone; Hibernate does not and should not worry about it.

I tried to implement this behavior and had problems on Hibernate 3.1.3, because I could not tell it not to use isFlag to retrieve values instead of getFlag, as both are valid bean acessor method names.

This probably can be solved by a field accessor definition, or by implementing any accessor strategy that will deal with the ambiguity, but couldn't there be an automatic check of some sort to prevent the problem from ocurring in the first place? Hibernate knows from my .hbm file which type is the field, and given two methods could realize on its own which one suits it.

Thanks

Hi,

I ran into the same issue yesterday and had about the same thoughts about possible enhancements, but those suggested might be major tasks.

What really hit me was when I found that hibernate's behaviour is undefined, when getFlag() and isFlag() both exist:
the BasicPropertyAccessor will call Class.getMethods() and choose the one of the above that comes first. But API-Documentation for getMethods() says "The elements in the array returned are not sorted and are not in any particular order", so you don't actually know which accessor will be chosen. I think this might well be worth a bug-report.

I think hibernate should always prefer getFlag() over isFlag() when both exist. Also this would only mean a minor correction in BasicPropertyAccessor.

Hello,

I agree with your proposal as I understod it:

1. Having Hibernate automatically choosing the right acessor method based on type as defined in a .hbm.xml file would be a nice enhancement in the long term, but

2. The current undefined behaviour should be reported as a bug.

If you want I can sum up both your remarks and mine, check the latest stuff on CVS and, if necessary, file a JIRA report on issue (2) above.

Yes, that would be great!

Thanks!