Sorry Jeff, I lost my mail server yesterday afternoon just found it this morning hiding under the rug:)
With regards to foreign relationships I thought about what you said and I think on the whole you¹re right. I don¹t want ibator (to avoid confusion, I¹ll stick with this name for now on) to become some OR/Hibernate clone. I spoke to some of my colleagues and what most impressed us about ibator was that it was able to provide us a with 60% functionality out of the box, so to speak. This enabled us to focus on the more complex 40% that was left. So we asked ourselves, do we really want/need foreign table support and why? It was a really positive discussion and what came about is that we felt the byExample functionality is the key feature that enabled us to quickly get our application out the door. What we¹re really looking for is a way to extend that to handle basic foreign relationships. In our example we felt that if ibator was able to provide this we would have had 80% maybe 90% functionality done with ibator alone. I guess what we¹re looking to do is have the ability to embed one example object into another where a foreign relationship exists. The complexity isn¹t in the SQL maps they¹re going to be reasonably straight forward, it¹s going to be in extending the example objects in a sensible way. For example lets look at the user/address relationship. They way I imagine it working is to have two example objects UserExample and AddressExample and creating a method in say addForeignCriteria which copies across the criteria from the foreign example object to the main this part may be easier than I thought???? I did a little more fleshing yesterday before I had to start rebuilding the mail server here¹s how far I got: Restrictions (anything beyond what¹s below should be handled on an as needs basis, not automated) 1. join based sql statements only I¹m not a fan of sub queries 2. one level only 3. only one 1:many relationship per table 4. insert and update functionality only on 1:1 relationships and where the foreign object is a primitive wrapper A quick and Dirty summary of functionality needed. 1. Creation of new xml child tag (something like foreignRelation) 2. creation of code to generate necessary xml code for sqmlMaps 3. expanding the example objects to facilitate foreign relationships 4. adding necessary DAO functionality for updates and inserts it doesn¹t make sense to implement this in SQL While the idea of doing this as an academic exercise sounds exciting, I¹d really only start down this road if there was genuine interest in it. At this stage I¹m looking for feedback. If there¹s interest there, I¹ll whack together a project plan on the weekend and post it to the wiki. Z.
