db-torque-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15334234#comment-15334234

Thomas Vandahl commented on TORQUE-343:

Yes I know about the extensibility. The use case I have in mind is the extension of persistent
classes in a library like in Fulcrum Security. You  are supposed to extend e.g. user objects
to match your requirements. Right now, we always need to configure the OM class *and* its
Peer class to handle this case. It would be easier to query the Torque instance for the PeerImpl
class for a given OM class.

Another use case I found are complex queries. I found it very useful to define separate (non-generated)
PeerImpl/RecordMapper classes to handle complex joins within custom-built objects. In the
end I found myself up creating those PeerImpl object instances over and over again because
I had no real place to store them. This is normally not necessary as these objects are thread

to be continued...

> 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