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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
