You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Gareth Moorst <ga...@yahoo.co.uk> on 2006/06/23 18:12:11 UTC

Abator wishlist

Hi List,

I've been using Ibatis for some time with manually written sqlmaps and daos, but now our development has moved up a notch and I'm looking at simplifying things by using Abator to generate our data access layer.

I've used it on a small scale, and had some success - I've found it very useful, I can't compliment it enough - but I always seem to have to manually edit the generated DAOs/Interfaces to make them consistent with the rest of our DAOs, or to add missing methods.

I'm not saying that we've done our DAOs right and the Abator ones are wrong, I'd just like them to be all the same.

The problems that I'm having (some tiny, some not quite so tiny) are:

The tables I generate my DAOs for normally have no constraints, no foreign keys, no primary keys at all - it'd be nice if I could override the database metadata to some extent, to tell Abator which fields should be updated, which fields should have a query method, etc. Something like this in the <table> definition:

  <table tableName="team">
    <uniqueKey columns="teamid" enableSelect="true" enableUpdate="true"/> 
    <columnOverride column="owner" updateable="false"/>
  </table>

which would tell Abator that the column 'teamid' in the team table can be considered a key column, and can have a 'selectByTeamId(String teamId)' method generated. The updateable property tells Abator that the owner column shouldn't be updated when calling 'updateByTeamId' method. Are there any reasons why we wouldn't be able to do something like this?

Most of the hand written domain objects I have are completely flat POJOs - there is no separate class for primary key - most of the time, there are no primary keys on the database - so I'd like all of the Abator generated objects to be the same. Can we turn off generation of primary key classes for those tables where primary keys are present and just use flat objects?

This is a tiny one - The generated interfaces have a different naming convention - the Abator classes all go 'insert(Thing)' whereas our handwritten ones all go 'insertThing(Thing)'. Is it possible to override the naming convention somehow? 
 
Is there a way to generate a selectAllThings() method? I know I could use the selectByExample(ThingExample) method, but I don't like to expose the ThingExample objects, so I turn them off. They're a great idea, and I can see how they could be very handy, but we don't use them and they'd be a pain to reproduce if we were ever to switch to another persistence technology.

Just a couple of thought about how I'd like to use Abator - what do you think?


Cheers,
Gareth Moorst