[dtbullock]

The title says it all. I have a legacy table which uses CHAR(1) fields and the chars ‘T’ and ‘F’ to represent boolean values. But on my Java class, I want to use ‘boolean isField()’ JavaBean semantics.

Here’s how (in decreasing order of enthusiasm) I’d like to be able to do it:

1) Be able to tell MyEclipse generate a .hbm.xml which specifies <property type=”net.me.MyBoolToCharMappingType”/> for columns of my choice and a .java bean which uses UserType.returnedClass() as the type of the property. Sweet!

2) Be able to tell MyEclipse that for columns of my choice, I wish to map them as <property access=”field”/> instead of property access=”property”/> and NOT write getters/setters for these columns, but let me write them myself in the subclass. Clunky, but OK.

Do I have either of these options in a workflow which uses the MyEclipse ‘Generate Hiberanate Mapping’ wizards? If not, are there *any* strategies which might satisfy both the mapping and the workflow? I know I could:

3) Simply add getters/setters in the subclass which provide a boolean view on the also-public string versions of the same properties. ie. as well as setFlag(String), I’d write setFlag(boolean t) { setFlag(t ? “T” : “F”) } … for each property 🙁

That’s a bit messy for me, since the ‘unsafe’ String-type setters are still exposed. Mitigation strategies exist (make the Bean implement a narrower interface and pass the interface around instead of the concrete type) but by now we’re starting to go to a lot of trouble and walking away from the ‘code automatically reflects the schema of the Database thanks to MyEclipse’ philosophy which MyEclipse espouses.

So my question, MyEclipse Zen masters, is ‘where lies the path of wisdom for char-based flags’?

thanks,
David.

[Riyad Kalla]

David,
Unfortunately there is no workaround to modifying our current mapper to support this. However, why can’t you just add custom methods to the Concrete subclasses that parse out the char values and return you the boolean true/false? For example:

(Generated) AbstractUser.java
— public String getUserActive();

(Generated once) User.java
— public boolean isUserActive(){return “T”.equals(getUserActive())};

Something like that?

[dtbullock]

OK, I’ll do that then. Just wanted to make sure I wasn’t overlooking an existing feature.

[dtbullock]

Mind you, it would be a great feature to have 🙂

[Riyad Kalla]

A lot of the functioanlity you described we are trying to address with our Visual Mapping tool that should eb in our 5.0 release if all goes according to plan. We realize the current impl is very limiting, we are also looking for some good improvements for the 4.1 release as well.

[Author]

Posts