[ezarecor]

I’m dealing with a table containing a column unfortunately named:

l_cd

When I generate hibernate mappings the mapping is as so:

<property name="lCd" column="l_cd" type="java.lang.String" />

The following getter is generated:

public java.lang.String getLCd()

And the following property:

private java.lang.String lCd;

And the following Exception:

[java] net.sf.hibernate.PropertyNotFoundException: Could not find a getter for lCd in class edu.harvard.itis.example.service.hibernate.Holder

The hibernate folks suggest that the JavaBean spec specifies that this property should be LCd — I don’t have time to verify this.

http://www.hibernate.org/116.html#A33

The testcase functions properly when this property is commented out of the mapping file.

[Riyad Kalla]

I have sent this bug to the hibernate developer. Also the only workaround for this now that I suggest is adding the correct property getter/setter to the concrete subclass of the generated POJO. In future releases of MyEclipse we will provide more control over the name and generation of the POJOS from the tables. Sorry you had to run into this.

[Kai Kretschmann]

@support-rkalla wrote:

I have sent this bug to the hibernate developer. Also the only workaround for this now that I suggest is adding the correct property getter/setter to the concrete subclass of the generated POJO. In future releases of MyEclipse we will provide more control over the name and generation of the POJOS from the tables. Sorry you had to run into this.

I trapped into this, too. Will it be fixed in the 4.0 end of april? It isn’t fun coding the getter and setters for all the attributes again.

[Riyad Kalla]

As I understand it, Hibernate is getting quite the kick in the pants for 4.0, so my information on this says yes this will be fixed.

[Christian Ashby]

This isn’t fixed in 4.0M2

My specific problem is a field called I_F_ADJ_AMT, property name=”iFAdjAmt”

Can someone tell me what the easiest way is to fix this? Write another getter/setter in the class?

[Christian Ashby]

Sorry for self-reply, but have worked out a quick fix: Renaming the properties in the XML (eg as IFAdjAmt) work.

I’ll just have to do this every time I rebuild…

[Finch]

Just wanted to post the same problem – and did some research for it (after all, I want to post “nice” bug reports 🙂
If a developer has already started investigating, he’s probably found out already.

Anyway, maybe this is of some help:
org.hibernate.property.BasicPropertyAccessor uses java.beans.Introspector.decapitalize(methodName.substring(3))

This is “usually” supposed to convert “getMyProperty” to “myProperty” and so on… (which is fine)

BUT look at the documentation at http://java.sun.com/j2se/1.4.2/docs/api/java/beans/Introspector.html#decapitalize(java.lang.String):

Utility method to take a string and convert it to normal Java variable name capitalization. This normally means converting the first character from upper case to lower case, but in the (unusual) special case when there is more than one character and both the first and second characters are upper case, we leave it alone.

Thus “FooBah” becomes “fooBah” and “X” becomes “x”, but “URL” stays as “URL”.

Ohhhh well… in the case of LCd (and ALL the other cases mentioned above), the name is NOT decapitalized because it starts with 2 uppercase letters. I don’t know if the assumption that “getLCd()” accesses a property “LCd” rather than “lCd” is a valid one (for getURL(), I can’t imagine a property URL!), but this will not change anytime soon in Hibernate or java.beans…

I think it’s up to MyEclipse to make sure the generated property names don’t have a lowercase letter as first character and an uppercase letter as a second character.
What can be done?
1) accessor “getLCd()”, property “LCd” (not nice, uppercase member??)
2) accessor “getlCd()”, property “lCd” (not nice, breaks “usual” Camel-notation)
3) accessor “getLcd()”, property “lcd” (probably best?)

Hope that helps 🙂
(and hope it will get fixed soon)

P.S.: As mentioned elsewhere (in the forum): As long as changes to the *.hbm.xml files are necessary (or desireable), I think we really need a way to regenerate the classes from the hbm.xml !!! (and btw: I would like to trigger regeneration from the hbm-files! They have all the info they need (incl. the referenced tablename) and I wouldn’t have to re-enter it every time!)
I’d like to habe the following options for *.hbm.xml: [1] regenerate classes from hbm-file [2] update hbm file from database [3] 2+1 🙂

[Riyad Kalla]

Finch,
Awesome followup, I’m sending this to the team working on Hibernate, thank you.

[Riyad Kalla]

Finch,
The naming issue goes away once we get our visual mapper in and the generation issue is actually in the pipeline to be added (I don’t think it will make 4.0, not sure).

[Finch]

Thanks for the update 🙂

Well, ok, then… I guess I’ll have to wait for the visual mapper – which is supposed to be a 4.0 feature according to the roadmap.

Speaking of which…. is there a roadmap update? Do you have a date for 4.0 Beta? 4.1 Beta?
The roadmap still says “4.1 Beta: Early August”. I guess there should be 4.0 Beta, 4.0 GA, 4.1 M1, 4.1 M2 (?) first… tight schedule ’til early August *g*

To get back on topic: Yes, the hibernate support in its current state is very helpful, but still clearly at a very err… “early development stage”. Therefore, I won’t even start posting my “big” RFEs because I’m sure you have dozens yourself.
HOWEVER… some of us start using it and I’d rather see a few “smaller” helpful things sooner than a “perfect” solution later (like November?). That’s why I suggested the context menu entries for .hbm.xml files. The visual mapper will probably require extensive new datastructures “under the hood”. The suggested context menu entries don’t need additional “input/persistent data” and should be done fairly quickly (assuming that the classes are now generated from the xml files and not from the database schema?) and would be a big help “in the short run” 🙂

Finch

[Author]

Posts