db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Vandahl ...@apache.org>
Subject Re: BasePeerImpl, was: Re: RFD: RecordMappers, Peers and MapBuilders
Date Sun, 29 Jul 2012 19:48:04 GMT
On 21.07.12 15:04, Thomas Fox wrote:
>> - I'd inject a RecordMapper<T>, the database name and a TableMap on
> creation of the
>> instance (setters and/or constructor)
> +1

Ok, this basically reduces the importance/usability of BasePeer but
increases the usability of BasePeerImpl. Maybe, BasePeer can go some day.

> 
>> - Move setDBName() to BasePeerImpl
> +1

This shows to simplify things a lot. Especially if you use generated
classes with different databases (of the same structure)

> 
>> - Move addSelectColumns() to BasePeerImpl by using
>> TableMap.getColumns()
> +1

Done. Works fine.

>> - Provide some kind of default record
>> mapper/default record to make calls like in doSelectVillageRecords()
>> work again.
> I do not understand this. You want to put the results in a map ?

Yes. More or less. There are cases where this is necessary, at least in
the code I maintain.

> 
>> - Remove the record mapper and the table map from the
>> various method signatures
> +1

What I did was to add the doSelect() methods from the generated
XXXBasePeerImpl but leave the methods in. They are explicitly used by
the doSelectJoin...() methods. Maybe we can make them protected.

> 
>> - Remove the then obsolete methods in the
>> generated PeerImpls.
> +1

The result is attached. And what remains from BaseAuthorPeerImpl, for
example. Actually, only the buildXXX() methods and the fillXXX() methods
must be generated, *if* we could make BasePeerImpl abstract or provide
some default implementation that throws a RuntimeException of sorts.

>> Question: -
>> Why do we have deprecated methods in a class that didn't even exist
>> in Torque 3.3? Is it just for keeping the old Criteria object alive?
> 
> It could allow for a soft transition form the old to the new criteria
> class.
> people just change the import but use the deprecated method...
> but maybe this scenario will not happen in practice, no idea.

I'm afraid this creates more confusion than it solves. The 4.0 release
should be expected to be incompatible, and then it's just a matter of
Ctrl+O in Eclipse to resolve that changed import. Just my 2 cents.


Bye, Thomas



Mime
View raw message