ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zoran Avtarovski <zo...@sparecreative.com>
Subject Re: [ANNOUNCE] Abator renamed to iBATOR
Date Wed, 16 Apr 2008 01:39:14 GMT
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.


View raw message