[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&focusedCommentId=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
[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&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 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] [Comment Edited] (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&focusedCommentId=15334234#comment-15334234 ] Thomas Vandahl edited comment on TORQUE-343 at 6/16/16 6:16 PM: 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 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. If BasePeerImpl were abstract, doSelect(obj), doInsert(obj), doUpdate(obj), doDelete(obj) and friends could be moved to BasePeerImpl and less code would be generated. Perhaps we introduce an abstract class derived from BasePeerImpl as a base class to the generated PeerImpl classes to make use of this fact. Then, an abstract method buildCriteria() could be placed there. was (Author: tv): 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