[jira] [Commented] (TORQUE-343) Implement a central registry for peerImpls like the registry for managers
[
https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409600#comment-15409600
]
Thomas Vandahl commented on TORQUE-343:
---
Never mind. I made a simple initial approach to test if the feature actually
can be used. It may turn out to be helpful to define some kind of generic
interface for peers, later.
> 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 BasePeerImpl getPeerFor(Class 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
[jira] [Commented] (TORQUE-343) Implement a central registry for peerImpls like the registry for managers
[
https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15400384#comment-15400384
]
Thomas Fox commented on TORQUE-343:
---
Sorry for pestering you with questions. Go ahead. I'm just fayouring storing
information locally instead of having registries where one always wonders when
the information is written there, so my intention was to grasp the motivation.
> 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 BasePeerImpl getPeerFor(Class 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
[jira] [Commented] (TORQUE-343) Implement a central registry for peerImpls like the registry for managers
[
https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15395360#comment-15395360
]
Thomas Vandahl commented on TORQUE-343:
---
About the complex query case:
Say, I have an application with a complex data model. I want to display a list
of data coming from different tables. So I create a query with lots of select
columns, several joins and a complex where-condition. This can be a pain to
handle.
So I apply the Peer/Mapper/OM-class pattern to this type of query by creating
an OM-class containing the select columns of my query, a mapper to map the
results to this object and a peerImpl to run the query. (An instance of
BasePeerImpl configured accordingly, will do, too).
This way, you can use the complex query like any other Peer/OM-class
combination. You may look at it as a kind of "dynamic view". The only caveat is
that a static peer class would be needed to avoid creating the peerImpl
instances. You /can/ do this, of course but I consider the registry method more
elegant.
> 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 BasePeerImpl getPeerFor(Class 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
[jira] [Commented] (TORQUE-343) Implement a central registry for peerImpls like the registry for managers
[
https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15395340#comment-15395340
]
Thomas Vandahl commented on TORQUE-343:
---
Yes, the use case is exactly as you describe. In general, in cases like these,
the convention is to configure the class name of the extended object somewhere.
In the Torque case, you would need to add a configuration for the peer class as
well. When using the registry I propose, I could simply ask Torque for the
implementation of a Peer for a given object without such extra configuration.
That's basically the idea I want to get across.
> 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 BasePeerImpl getPeerFor(Class 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
[jira] [Commented] (TORQUE-343) Implement a central registry for peerImpls like the registry for managers
[
https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 BasePeerImpl getPeerFor(Class 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
[jira] [Commented] (TORQUE-343) Implement a central registry for peerImpls like the registry for managers
[
https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 safe.
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 BasePeerImpl getPeerFor(Class 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
[jira] [Commented] (TORQUE-343) Implement a central registry for peerImpls like the registry for managers
[
https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1524#comment-1524
]
Thomas Fox commented on TORQUE-343:
---
You can already dynamically extend and exchange the PeerImpls by
SomePeer.setSomePeerImpl() method. It is already kind of a distributed
registry. Would the SomePeers query the registry instead of storing the
PeerImpls locally?
Also a central registry has the problem of type safety. The PeerImpls are
currently generic, yet there are some methods which are generated for some
PeerImpls but not for others (e.g. retrieveByPK(String, int, String, Integer,
Byte, Short, Long, Double, Double, Date) is generated for BaseMultiPkPeerImpl
but not for BaseAuthorPeerImpl) which would require explicit casts if the type
of the returned PeerImpl is not known.
Where would the registry be used? If you can point to some use cases, I could
better make up my opinion.
As for moving the buildCriteria(obj) to the RecordMapper, I'd rather not do
this. Currently, a RecordMapper has the single purpose to map a database record
to the Object. So if one has as strange database structure one has to read, one
can easily implement the RecordMapper interface to perform the mapping
manually. See e.g. the clases in org.apache.torque.om.mapper. Moving other
functionality into this interface would impede this function in my opinion.
However, I'd rather suggest to cerate another object which is responsible for
creating the other way round (object to database) (name suggestion:
...Selector) which then would contain the buildCriteria(Object) method (as well
as perhaps the other build...CriteriaMethods). However this would again
increase the number of created classes, so I am not sure whether this does not
add too much complexity.
As for moving the buildCriteria(obj) to the table map: The table map is
currently not a generated class. How would you accesss the relevant getters for
the data object there?
Again, can you provide a reson why it would be favorable to move the
buildCriteria(obj) method?
> 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 BasePeerImpl getPeerFor(Class 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
