> That said; Why do you even want to involve Hibernate? From my PoV it adds > zero value as an ES. IBatis maybe... curious of your thinking.
I am not so sure of that zero figure. You get at least limited portability for free. You get a lot more if you choose to enable value-added features but I think this is a provision for the future not for the limited functionality that you were looking for. In the case of the limited functionality required you are still getting the most for your (or my) effort. For example, schema generation. Auto-magic mappings of fields. E.g., <property type="long" name="blah" /> and hibernate declares feasible types in dfferent DBs. I do not envisions people moving from one DB to the other (as I never seen this done in practice, contrary to promises of all the ORMs out there that it is possible) but I do believe ppl will try QRM functionality with different DBs at the very least, heck I do. Up until recently I did not believe Hibernate was even a possibility, as I thought it needed java beans to map them to DB, which are not available in QRM. This however is not a requirement as hibernate has dynamic-class (this is the old name) feature, where you can stuff a map with values of named properties and given a hibernate mapping along, Hibernate is able to persist that map. Sounds like an EntityState. Very nifty for our requirement to configure everything on-the-fly. I am not extremely familiar with iBatis - I worked with it only once and it was a long time ago. Not too long ago though, I wanted to re-implement GORM in it and I had trouble of configuring iBatis dynamically (on startup) as it was required by GORM. So that was a show stopper then and it will be in QRM. Programmatic configuration I believe is available in version 3 of iBatis but I have not had a close look at it yet. Hibernate is totally programmable in terms of its configuration and mappings. Last but not least: hibernate after all is the one mapping technology I am most familiar with. I also looked at spring jdbc module ... but the amount of work there is just too much. With all of the above I am keeping an eye on making mapper itself swappable in case we want to swap (very unlikely, but ... should be doable) Alex. _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
