db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Monroe <Greg.Mon...@dukece.com>
Subject RE: RFD: RecordMappers, Peers and MapBuilders
Date Mon, 16 Jul 2012 14:24:03 GMT
I agree with Thomas F's analysis.  There are three different sets of
responsibilities here.  I would paraphrase them as:

PeerImpl - Manage interactions with a "table"
RecordMapper - Serves the same purpose as JDBC's ResultSetMetaData 
               and contain info to map SQL **QUERIES** to objects.
MapBuilders - Similar to JDBC's DatabaseMetaData - Allows code to 
              determine the underlying DB structure.

I think mixing responsibility in order to cut back classes would
lead to more confusion / complexity.

-----Original Message-----
From: Thomas Fox [mailto:Thomas.Fox@seitenbau.net] 
Sent: Monday, July 16, 2012 3:45 AM
To: Apache Torque Developers List
Subject: RE: RFD: RecordMappers, Peers and MapBuilders

Thomas Vandahl wrote:
> when fiddling with the LargeSelect class I stumbled across the 
> necessity to add SELECT columns as well as the requirement of a 
> RecordMapper. I came to think that it would be helpful to concentrate 
> the information about a table and its structure into one class, 
> preferably not with static methods. Currently, this information is 
> distributed over three classes, the RecordMapper, the Peer and the MapBuilder.
> I believe that this might even help to reduce the amount of code that 
> needs to be generated by using sophisticated generics. Just some
> - RecordMapper provides a List of Column objects that can be used by 
> the Peer (or LargeSelect, for that matter).
> - The BasePeerImpl<T> gets a static member variable of type
> - The MapBuilder could be merged into the RecordMapper, no longer 
> static
> - Several PeerImpl methods could be moved into BasePeerImpl<T>

Am I right that you are addressing two different points here ?
1) Whether or not we need the Peer, RecordMapper and MapBuilder classes as different classes
2) Whether or not to generify the BasePeerImpl class ?

If yes, looking at 1)
Let's consider the options we have
a) leave  Peer, RecordMapper and MapBuilder as different classes
b) put the MapBuilder functionality into the RecordMapper class
c) put the RecordMapper functionality into the PeerImpl class
d) put both the RecordMapper and MapBuilder functionality into the PeerImpl class Let's also
consider what the objects are meant to be:
- RecordMapper knows how to map a Record to a Data Object
- Peer knows how to access the database table
- MapBuilder is responsible for building a Runtime representation of the database structure.
This structure is used almost exclusively by the Peer class
- (we do not consider Data objects here)

We have explicit database structure in
- The peer's static fields
- the map builder when filling the runtime structure
- AFAIK there is no explicit information about database structure in the RecordMapper class
(meaning you cannot ask at the Record mapper class and determine which colums exist in the
database columns)

There is an implicit database structure in every class we generate (e.g the class name corresponds
to a table name, or the getters and setters in the Data object class correspond to the columns
in the database)

So, when there was the wish to concentrate the explicit database information, I'd concentrate
it in the peer class and not in the RecordMapper class (as there is not yet this info, and
it also is not the meaning of the class).
There is no hard reason I am aware of why we can not concentrate all functionality in one
class. The main soft reason is that we now have a nice separation of concerns in different
classes. On the other hand, concentrating the classes would mean a simpler class structure.
My tendency would be to leave the class structure as it is, but I'd also be ok with a different

2) Considering the generics part, I need to play around a bit. I am using generics only in
simple ways on a daily basis and need to get familiar with the more complicated possibilities.
I agree that there could be the possibility to move generated code into the base classes.
I Will try to play around with generics a bit in the next time (i.e. weeks,
likely) and come back with my findings. In principle, generifying BasePeerImpl seems to be
a good idea, so if you want to have a shot, please do so.


To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

DukeCE Privacy Statement:
Please be advised that this e-mail and any files transmitted with
it are confidential communication or may otherwise be privileged or
confidential and are intended solely for the individual or entity
to whom they are addressed. If you are not the intended recipient
you may not rely on the contents of this email or any attachments,
and we ask that you please not read, copy or retransmit this
communication, but reply to the sender and destroy the email, its
contents, and all copies thereof immediately. Any unauthorized
dissemination, distribution or copying of this communication is
strictly prohibited.

To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message