Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <5005CE65.2040203@apache.org>
Date: Tue, 17 Jul 2012 22:43:17 +0200
From: Thomas Vandahl <tv@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Apache Torque Developers List <torque-dev@db.apache.org>
Subject: Re: RFD: RecordMappers, Peers and MapBuilders
References: <4FFC850B.1090509@apache.org>
 <OF6DF72714.8AA2C71E-ONC1257A39.00293525-C1257A3D.002A925A@seitenbau.net>
 <50046802.3070903@apache.org>
 <OFC4E6417C.470324FB-ONC1257A3E.002D62DE-C1257A3E.002FBA8B@seitenbau.net>
In-Reply-To: 
 <OFC4E6417C.470324FB-ONC1257A3E.002D62DE-C1257A3E.002FBA8B@seitenbau.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 17.07.12 10:41, Thomas Fox wrote:
> Probably we can add the MapBuilder's methods as protected methods to the
> Peer class, without even changing the Peer public interface. On the first
> look, this looks like a good idea, and the public API stays the same for
> the Peers, so it's better for the user (less generated classes) (and in my
> opinion, the additional two or three protected methods in the generated
> peers do not make the class too complicated.

+1

> Thinking again about dissolving the RecordMapper into the PeerImpl class,
> this would add one public method (and a bunch of protected methods, one for
> each column) to the PeerImpl class. Which is again probably acceptable for
> the user, but adds still more complexity to the peers.

+0

> Dissolving the RecordMapper into the PeerImpl class is also problematic
> because the Data Object classes can have protected getters and setters for
> some fields (whenever the user sets protected="true" on a column), so the
> RecordMapper must be in the same package as the data object class. We also
> cannot make it protected because the peer class can be in another package
> (at the moment).

Let me dig around a bit. Maybe some of the dependency injection patterns
can help.

> Regarding the Peer and PeerImpl classes, of course we can go back to just
> static methods, with all their problems (e.g. cannot be exchanged on
> runtime, e.g. for unit testing).

No, please don't even consider this. I'd rather strive to reduce statics
in Torque much as possible.

> We could also look at a compile-time switch to generate either just static
> methods or impl classes, (but we have a lot of switches already, which does
> not make testing easier).

Rather not. What about a single static method getPeer() that returns the
PeerImpl in the data objects? IIRC, its already there only not static.

> What are your opinions ? I'm undecided.

I'll see how far I can get with a generified BasePeerImpl. Maybe the
starting point is then easier to see.

Bye, Thomas.

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