David Mob

Greenhorn
+ Follow
since Oct 25, 2010
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by David Mob

SOLVED!

i hadn't noticed until today but a TIMESTAMP field in the table was reverse generated into....

private Serializable lastActUpDateTime;

that looked odd, so i change it to...

private java.util.Date lastActUpDateTime;

and my problem went away.
well...all i did was identify the "bad" column. i don't actually have a fix (yet?!?). but i do appreciate your enthusiasm that i *will* solve it.
i guess i should show you how ParentObdElementId works....

i was finally able to identify the problematic column...."parent_obd_element_id". when i removed it from the table, and remapped the class i was able to run "findAll()" successfully. now the big question: why? that column is, of course, the parent element_id of a given row. whether it maps as a Long parentObdElementId or as an instance of the class ObdElement obdElement doesn't seem to matter (in both cases i get the exception).
i have a table defined as...


reverse engineering it via Hibernate i get the following...(setters omitted for brevity)


when i call my Dao object's "FindAll()" i get...


i have tried commenting out the Set (obdElements), but get the same results. i have tried remapping *by hand* PARENT_OBD_ELEMENT_ID to be a Long parentObdElementId instead of an instance of ObdElement...still no go. i've actually always had good luck with reverse engineering tables...until now. i noticed that the NOT NULL columns are mapped to "long", and the nullable columns (that contain Ids) are mapped to "Long". any ideas? i'll keep looking 'round the web for ideas.

thanks....