db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Fox (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TORQUE-343) Implement a central registry for peerImpls like the registry for managers
Date Wed, 27 Jul 2016 05:17:20 GMT

    [ 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
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

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

View raw message