[
https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15395057#comment-15395057
]
Thomas Fox commented on TORQUE-343:
-----------------------------------
Let me see if I grasp the fulcrum case:
- There is a FulcrumUser object provided py fulcrum and the implementer wants
an attribute in the User object which is not in BaseUser, so an Object User
extends FulcrumUser is created which has the additional attribute. But then,
the Peer class must need to know how to read and write this attribute from/to
the database, so the FulcrumUserPeer needs to be extended as well? I do not see
a way to get around that...
Regarding the complex query use case, there are two places where you need to
write code:
- The composition of the Query, which would by convention be in the Peer class
- The mapping of the Query Result to the object, which would by convention be
in the Record Mapper
What is the reason why you use separate classes? And if you use separate
classes, is there still only one peer for one object class?
No objection against moving code to a generated BaseAbstractPeerImpl (or
whatever you call it :-) )
> Implement a central registry for peerImpls like the registry for managers
> -------------------------------------------------------------------------
>
> Key: TORQUE-343
> URL: https://issues.apache.org/jira/browse/TORQUE-343
> Project: Torque
> Issue Type: Improvement
> Components: Runtime, Templates
> Affects Versions: 4.0
> Reporter: Thomas Vandahl
> Assignee: Thomas Vandahl
> Fix For: 4.1
>
>
> I'd like to suggest a central registry for peerImpl-objects which can be
> queried by the Persistent class it is responsible for. This would allow
> reusing and extending the peer objects dynamically as well as giving them
> some kind of life-cycle.
> The main method would be similar to this:
> {code:java}
> public <T> BasePeerImpl<T> getPeerFor(Class<T> persistentClass)
> {
> return peerRegistry.get(persistentClass);
> }
> {code}
> I would also like to suggest moving the buildCriteria(obj) method to the
> RecordMapper or the TableMap class. This will further reduce the amount of
> code that needs to be generated.
> If the idea is received well, I'll come up with a proposal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
