Jenkins build is back to normal : Torque4-trunk #560

[Apache Jenkins Server]

See 


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

Jenkins build is back to normal : torque4-test-project-hsqldb #342

[Apache Jenkins Server]

See 


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

Jenkins build is back to normal : torque4-test-project-hsqldb » Torque Test Project #342

[Apache Jenkins Server]

See 



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

Jenkins build is back to normal : torque4-test-project-derby #427

[Apache Jenkins Server]

See 


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

Jenkins build is back to normal : torque4-test-project-derby » Torque Test Project #427

[Apache Jenkins Server]

See 



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

[jira] [Commented] (TORQUE-346) Introduce abstract layer for peer impl to reduce the amount of generated code

[Thomas Fox (JIRA)]

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

Thomas Fox commented on TORQUE-346:
---

I'm not sure what you mena by "availability of a primary key". 
If you mean that the object is already in dthe database and thus has a primary 
key, the answer is no (see e.g. org.apache.torque.test.dbobject.base.BaseExt in 
the test project, which has a primitive primary key which always is set and 
thus obj.getPrimaryKey() will never return null). 
If you mean whether the table has a PK at all, this will probably work 
currently, although it is not documented. However, for me it would be cleaner 
to store this information in the table map instead of relying on the 
obj.getPrimaryKey() method.

> Introduce abstract layer for peer impl to reduce the amount of generated code
> -
>
> Key: TORQUE-346
> URL: https://issues.apache.org/jira/browse/TORQUE-346
> Project: Torque
>  Issue Type: Improvement
>  Components: Runtime, Templates
>Affects Versions: 4.0
>Reporter: Thomas Vandahl
>Assignee: Thomas Vandahl
> Fix For: 4.1
>
>
> Several methods in PeerImpl rely on buildCriteria() and buildColumnValues() 
> respectively. An intermediate layer of AbstractPeerImpl can be used to 
> concentrate these methods in a central class and reduce the amount of 
> generated code duplication.



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

[Thomas Fox (JIRA)]

[ 
https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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