db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fox <Thomas....@seitenbau.net>
Subject RE: RFD: RecordMappers, Peers and MapBuilders
Date Mon, 16 Jul 2012 07:44:57 GMT
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
thoughts:
>
> - 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
RecordMapper<T>.
> - 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 decision.


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.

    Thomas


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


Mime
View raw message