ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: [JDBC type = ARRAY / Java type = ?] Support for Primary Key using Composition instead of inheritance
Date Thu, 22 Feb 2007 14:38:03 GMT
I understand about the psuedo primary key thing and we've discussed it
before.  My take on it is that it is very simple to write a pseudo
"selectByPrimaryKey" function by reusing the selectByExample method.  This
gives you complete flexibility with how the keys are defined without adding
a lot of complexity to Abator.

For example:

public SomeTable selectByPrimaryKey(Integer id) {
  SomeTableExample example = new SomeTableExample();
  example.createCriteria().andIdEqualTo(id);
  List<SomeTable> records = selectByExample(example);
  return records.size() == 1 ? records.get(0) : null;
}

Jeff Butler



On 2/22/07, bkbonner <brian.bonner@paraware.com> wrote:
>
>
> Jeff, thanks for the information.  I'd rather not use a flat type, since
> many
> of the keys for this old model I'm working with are composite keys.
>
> I looked at the source and found the JavaModelGenerator and the two
> implementations in the "internal" package.  I will look at the extending
> abator section.
>
> I knew there was no support for this currently, but I thought it would be
> something that might be useful to add for folks (like me in this case)
> that
> don't have control over what the DBAs are doing on the database.  In other
> words, I want it to generate the mapping and model code as if they were
> primary keys until the DBAs catchup with their changes.
>
> Brian
>
>
> Jeff Butler-2 wrote:
> >
> > You can tell Abator to not generate a seperate class for the primary
> key.
> > Specify a default model type of "flat" on your abator context.  This
> would
> > put all the fields in one class.
> >
> > If you want to use composition instead of inheritance, then you'd need
> to
> > write your own JavaModelGenerator implementation.  There is some
> > information
> > about how to do this in the abator documentation (see the section on
> > extending abator).
> >
> > As far as specifying the primary keys in the config, there's no support
> > for
> > this.  You can achieve the same effect by reusing the selectByExample
> > method
> > - write specific selectByXXX methods that take the psuedo primary keys
> as
> > parameters.
> >
> > Jeff Butler
> >
> >
> > On 2/21/07, bkbonner <brian.bonner@paraware.com> wrote:
> >>
> >>
> >> I would like to change how abator handles the mapping of files to use
> >> composition of the primary keys instead of inheritance.  Inheritance of
> >> the
> >> primary key seems a little awkward to me.
> >>
> >> Do you have any suggestions as to how what I would change to let abator
> >> include this new behavior?
> >>
> >> I'd also like to be able to specify the override the columns of the
> >> primary
> >> key in the abator config file for old broken models that don't have
> >> primary
> >> keys defined where the DBAs won't change the database to apply the
> >> primary
> >> key.
> >>
> >> Any suggestions here would be helpful, too.
> >>
> >> Thanks.
> >>
> >> Brian
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Support-for-Primary-Key-using-Composition-instead-of-inheritance-tf3269344.html#a9089343
> >> Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Support-for-Primary-Key-using-Composition-instead-of-inheritance-tf3269344.html#a9100704
> Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
>
>

Mime
View raw message