[jira] [Resolved] (TORQUE-167) Remove the field Criteria.Criterion.db
[ https://issues.apache.org/jira/browse/TORQUE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-167. --- Resolution: Fixed Fix Version/s: 4.0 > Remove the field Criteria.Criterion.db > -- > > Key: TORQUE-167 > URL: https://issues.apache.org/jira/browse/TORQUE-167 > Project: Torque > Issue Type: Improvement > Components: Runtime >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.0 > > > The db field of the Criterion specifies which database dialect is used for > rendering this Criterion in SQL. > In my opinion the database dialect should be determined from a criteria > field, not from any nested object. > Implications: > As a criterion is no standalone class, but an inner class of a Criteria, it > always has a criteria attached and its SQL is only rendered in the context of > this criteria. As the criteria has a field dbName by which the db adapter can > be found out via Torque.getDB(criteria.getDbName()), I propose to remove the > db field from Criterion together with its getters and setters and use the > dbName field of the criteria instead to determine which Adapter should be > used. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
svn commit: r1147286 - in /db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque: sql/SqlBuilder.java util/Criteria.java
Author: tfischer
Date: Fri Jul 15 19:16:02 2011
New Revision: 1147286
URL: http://svn.apache.org/viewvc?rev=1147286&view=rev
Log:
TORQUE-167: remove the field db from Criteria.Criterion
Modified:
db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/sql/SqlBuilder.java
db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/util/Criteria.java
Modified:
db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/sql/SqlBuilder.java
URL:
http://svn.apache.org/viewvc/db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/sql/SqlBuilder.java?rev=1147286&r1=1147285&r2=1147286&view=diff
==
---
db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/sql/SqlBuilder.java
(original)
+++
db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/sql/SqlBuilder.java
Fri Jul 15 19:16:02 2011
@@ -387,7 +387,6 @@ public final class SqlBuilder
Query query)
throws TorqueException
{
-criterion.setDB(db);
String tableName = criterion.getTable();
if (tableName != null)
@@ -439,7 +438,7 @@ public final class SqlBuilder
= buildPs(
whereClausePartInput,
ignoreCase,
-criterion.getDb());
+db);
sb.append(whereClausePartOutput.getSql());
query.getPreparedStatementReplacements().addAll(
whereClausePartOutput.getPreparedStatementReplacements());
Modified:
db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/util/Criteria.java
URL:
http://svn.apache.org/viewvc/db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/util/Criteria.java?rev=1147286&r1=1147285&r2=1147286&view=diff
==
---
db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/util/Criteria.java
(original)
+++
db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/util/Criteria.java
Fri Jul 15 19:16:02 2011
@@ -38,7 +38,6 @@ import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.torque.Torque;
import org.apache.torque.TorqueException;
-import org.apache.torque.adapter.DB;
import org.apache.torque.om.ObjectKey;
/**
@@ -3068,12 +3067,6 @@ public class Criteria implements Seriali
private boolean ignoreStringCase = false;
/**
- * The DB adaptor which might be used to get db specific
- * variations of sql.
- */
-private DB db;
-
-/**
* other connected criteria.
*/
private List clauses = new ArrayList();
@@ -3234,53 +3227,6 @@ public class Criteria implements Seriali
}
/**
- * Get the value of db.
- * The DB adaptor which might be used to get db specific
- * variations of sql.
- * @return value of db.
- */
-public DB getDb()
-{
-if (this.db == null)
-{
-// db may not be set if generating preliminary sql for
-// debugging.
-try
-{
-return Torque.getDB(getDbName());
-}
-catch (Exception e)
-{
-// we are only doing this to allow easier debugging, so
-// no need to throw up the exception, just make note of it.
-log.error(
-"Could not get a DB adapter, so sql may be wrong");
-return null;
-}
-}
-else
-{
-return this.db;
-}
-}
-
-/**
- * Set the value of db.
- * The DB adaptor might be used to get db specific
- * variations of sql.
- * @param v Value to assign to db.
- */
-public void setDB(DB v)
-{
-this.db = v;
-
-for (int i = 0; i < this.clauses.size(); i++)
-{
-((clauses.get(i))).setDB(v);
-}
-}
-
-/**
* Sets ignore case.
*
* @param b True if case should be ignored.
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Updated] (TORQUE-167) Remove the field Criteria.Criterion.db
[ https://issues.apache.org/jira/browse/TORQUE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox updated TORQUE-167: -- Summary: Remove the field Criteria.Criterion.db (was: Remove the filed Criteria.Criterion.db) > Remove the field Criteria.Criterion.db > -- > > Key: TORQUE-167 > URL: https://issues.apache.org/jira/browse/TORQUE-167 > Project: Torque > Issue Type: Improvement > Components: Runtime >Reporter: Thomas Fox >Assignee: Thomas Fox > > The db field of the Criterion specifies which database dialect is used for > rendering this Criterion in SQL. > In my opinion the database dialect should be determined from a criteria > field, not from any nested object. > Implications: > As a criterion is no standalone class, but an inner class of a Criteria, it > always has a criteria attached and its SQL is only rendered in the context of > this criteria. As the criteria has a field dbName by which the db adapter can > be found out via Torque.getDB(criteria.getDbName()), I propose to remove the > db field from Criterion together with its getters and setters and use the > dbName field of the criteria instead to determine which Adapter should be > used. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-167) Remove the filed Criteria.Criterion.db
Remove the filed Criteria.Criterion.db -- Key: TORQUE-167 URL: https://issues.apache.org/jira/browse/TORQUE-167 Project: Torque Issue Type: Improvement Components: Runtime Reporter: Thomas Fox Assignee: Thomas Fox The db field of the Criterion specifies which database dialect is used for rendering this Criterion in SQL. In my opinion the database dialect should be determined from a criteria field, not from any nested object. Implications: As a criterion is no standalone class, but an inner class of a Criteria, it always has a criteria attached and its SQL is only rendered in the context of this criteria. As the criteria has a field dbName by which the db adapter can be found out via Torque.getDB(criteria.getDbName()), I propose to remove the db field from Criterion together with its getters and setters and use the dbName field of the criteria instead to determine which Adapter should be used. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-166) remove the getOMClass() method, the CLASS_DEFAULT constant and the initClass() method in the generated peers
[ https://issues.apache.org/jira/browse/TORQUE-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066038#comment-13066038 ] Thomas Fox commented on TORQUE-166: --- This was discussed on the dev list, see http://mail-archives.apache.org/mod_mbox/db-torque-dev/201105.mbox/%3cof47d897b4.2412951a-onc125788b.00405c58-c125788b.006e2...@seitenbau.net%3E and followups > remove the getOMClass() method, the CLASS_DEFAULT constant and the > initClass() method in the generated peers > > > Key: TORQUE-166 > URL: https://issues.apache.org/jira/browse/TORQUE-166 > Project: Torque > Issue Type: Improvement >Reporter: Thomas Fox >Assignee: Thomas Fox > > These methods and constants were used by village and are not needed any more. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-166) remove the getOMClass() method, the CLASS_DEFAULT constant and the initClass() method in the generated peers
remove the getOMClass() method, the CLASS_DEFAULT constant and the initClass() method in the generated peers Key: TORQUE-166 URL: https://issues.apache.org/jira/browse/TORQUE-166 Project: Torque Issue Type: Improvement Reporter: Thomas Fox These methods and constants were used by village and are not needed any more. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-166) remove the getOMClass() method, the CLASS_DEFAULT constant and the initClass() method in the generated peers
[ https://issues.apache.org/jira/browse/TORQUE-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox reassigned TORQUE-166: - Assignee: Thomas Fox > remove the getOMClass() method, the CLASS_DEFAULT constant and the > initClass() method in the generated peers > > > Key: TORQUE-166 > URL: https://issues.apache.org/jira/browse/TORQUE-166 > Project: Torque > Issue Type: Improvement >Reporter: Thomas Fox >Assignee: Thomas Fox > > These methods and constants were used by village and are not needed any more. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-163) Map builders are emptied on Torque.shutdown() and not rebuilt on subsequent init()
[ https://issues.apache.org/jira/browse/TORQUE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-163. --- Resolution: Fixed Fix Version/s: 4.0 > Map builders are emptied on Torque.shutdown() and not rebuilt on subsequent > init() > -- > > Key: TORQUE-163 > URL: https://issues.apache.org/jira/browse/TORQUE-163 > Project: Torque > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.0 > > > Problem: After a shutdown() and init() of Torque, the Map Builder cache > entries which have been present before shutdown are not present anymore after > a new init. > Analysis: If a Peer class is loaded, it registers its map builder and the > MapBuilder is built immediately or on Torque initialisation, depending on > whether Torque is initialized or not. > On Torque.shutdown(), all known map builders are removed. > On a new init(), these Map builders will not be rebuilt anew because the Peer > class will not be loaded a second time. > Solution: The Map Builder cache entries should not be removed on > Torque.shutdown() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-165) Implement cascading deletes
[ https://issues.apache.org/jira/browse/TORQUE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066021#comment-13066021 ] Thomas Fox commented on TORQUE-165: --- Cascading deletes for known foreign keys is quite easy to implement and one could imagine use cases where one would want to determine at run time whether one wants to have a cascaded delete or not (though I do not currently can imagine one). The reason I entered this issue is that there was a sort of cascading delete implemented in 3.3 but I never found out how it worked and whether it worked at all (I 'd bet on the second), so I thought it was no good dropping out features from 3.3. But I'm ok with not implementing cascading deletes in Torque. However, to have a clean API, this would mean to drop the cascade flag on criteria. If nobody speaks up in favour of this feature in a few days I'll remove the cascade flag on criteria and close the issue as wontfix. > Implement cascading deletes > --- > > Key: TORQUE-165 > URL: https://issues.apache.org/jira/browse/TORQUE-165 > Project: Torque > Issue Type: Improvement >Reporter: Thomas Fox >Assignee: Thomas Fox > > If the flag criteria.cascade is set to true and a detelete() method is called > on a peer class, all rows ehich are referenced by the deleted rows should be > deleted as well, including rows which are referenced indirectly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-163) Map builders are emptied on Torque.shutdown() and not rebuilt on subsequent init()
[ https://issues.apache.org/jira/browse/TORQUE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066012#comment-13066012 ] Thomas Fox commented on TORQUE-163: --- I agree. But changing the peer registration process means a lot of concept-thinking and testing. For now I'm content to just make the eclipse test work. > Map builders are emptied on Torque.shutdown() and not rebuilt on subsequent > init() > -- > > Key: TORQUE-163 > URL: https://issues.apache.org/jira/browse/TORQUE-163 > Project: Torque > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Thomas Fox >Assignee: Thomas Fox > > Problem: After a shutdown() and init() of Torque, the Map Builder cache > entries which have been present before shutdown are not present anymore after > a new init. > Analysis: If a Peer class is loaded, it registers its map builder and the > MapBuilder is built immediately or on Torque initialisation, depending on > whether Torque is initialized or not. > On Torque.shutdown(), all known map builders are removed. > On a new init(), these Map builders will not be rebuilt anew because the Peer > class will not be loaded a second time. > Solution: The Map Builder cache entries should not be removed on > Torque.shutdown() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
svn commit: r1147194 - /db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/TorqueInstance.java
Author: tfischer
Date: Fri Jul 15 15:35:45 2011
New Revision: 1147194
URL: http://svn.apache.org/viewvc?rev=1147194&view=rev
Log:
TORQUE-163: Do not empty map builders on shutdown
Modified:
db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/TorqueInstance.java
Modified:
db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/TorqueInstance.java
URL:
http://svn.apache.org/viewvc/db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/TorqueInstance.java?rev=1147194&r1=1147193&r2=1147194&view=diff
==
---
db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/TorqueInstance.java
(original)
+++
db/torque/torque4/trunk/torque-runtime/src/main/java/org/apache/torque/TorqueInstance.java
Fri Jul 15 15:35:45 2011
@@ -99,7 +99,9 @@ public class TorqueInstance
* are serialized then unserialized prior to Torque being reinitialized.
* This condition exists in a normal catalina restart.
*/
-private Map mapBuilderCache = null;
+private Map mapBuilderCache
+= Collections.synchronizedMap(new HashMap());
+;
/**
* Creates a new instance with default configuration.
@@ -114,7 +116,7 @@ public class TorqueInstance
/**
* Initializes this instance of Torque.
*
- * @throws TorqueException if Torque is already initialized
+ * @throws TorqueException if Torque is already initialized
* or an error during initialization occurs.
*/
private synchronized void initialize() throws TorqueException
@@ -748,8 +750,6 @@ public class TorqueInstance
*/
private void resetConfiguration()
{
-mapBuilderCache = Collections.synchronizedMap(
-new HashMap());
managers = new HashMap();
isInit = false;
}
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-165) Implement cascading deletes
[ https://issues.apache.org/jira/browse/TORQUE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066010#comment-13066010 ] Thomas Vandahl commented on TORQUE-165: --- Well, in my book cascading deletes would be the task of the database. It knows best what to do. Don't you think we should drop this as a feature? I never understood why it was there in the first place. Torque only knows about cascades based on foreign keys anyway. Besides, to be exact, it would be necessary to consider the value of onDelete when implementing this. > Implement cascading deletes > --- > > Key: TORQUE-165 > URL: https://issues.apache.org/jira/browse/TORQUE-165 > Project: Torque > Issue Type: Improvement >Reporter: Thomas Fox >Assignee: Thomas Fox > > If the flag criteria.cascade is set to true and a detelete() method is called > on a peer class, all rows ehich are referenced by the deleted rows should be > deleted as well, including rows which are referenced indirectly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-163) Map builders are emptied on Torque.shutdown() and not rebuilt on subsequent init()
[ https://issues.apache.org/jira/browse/TORQUE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066004#comment-13066004 ] Thomas Vandahl commented on TORQUE-163: --- Agreed. The general idea of the Avalon lifecycle contract is the symmetry of initialize/dispose, start/stop etc. So the requirement would be that dispose() or shutdown() left the component or instance in the same state as it was before the first initialize() or init(). Clearly this doesn't work the way Torque is designed right now. Nevertheless, my humble opinion is that we should strive to remove as much static stuff as possible from Torque to reach that goal one day. A clean lifecycle is a Good Thing(TM), be it Avalon or not. > Map builders are emptied on Torque.shutdown() and not rebuilt on subsequent > init() > -- > > Key: TORQUE-163 > URL: https://issues.apache.org/jira/browse/TORQUE-163 > Project: Torque > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Thomas Fox >Assignee: Thomas Fox > > Problem: After a shutdown() and init() of Torque, the Map Builder cache > entries which have been present before shutdown are not present anymore after > a new init. > Analysis: If a Peer class is loaded, it registers its map builder and the > MapBuilder is built immediately or on Torque initialisation, depending on > whether Torque is initialized or not. > On Torque.shutdown(), all known map builders are removed. > On a new init(), these Map builders will not be rebuilt anew because the Peer > class will not be loaded a second time. > Solution: The Map Builder cache entries should not be removed on > Torque.shutdown() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-165) Implement cascading deletes
[ https://issues.apache.org/jira/browse/TORQUE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065992#comment-13065992 ] Thomas Fox commented on TORQUE-165: --- There are two ways to implement this. The first is in Base peer by traversing the database map. The second is in the generated Peers. Because the generated code is easier to read and also easier to override, I'd like to go for the second option. > Implement cascading deletes > --- > > Key: TORQUE-165 > URL: https://issues.apache.org/jira/browse/TORQUE-165 > Project: Torque > Issue Type: Improvement >Reporter: Thomas Fox > > If the flag criteria.cascade is set to true and a detelete() method is called > on a peer class, all rows ehich are referenced by the deleted rows should be > deleted as well, including rows which are referenced indirectly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-165) Implement cascading deletes
[ https://issues.apache.org/jira/browse/TORQUE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox reassigned TORQUE-165: - Assignee: Thomas Fox > Implement cascading deletes > --- > > Key: TORQUE-165 > URL: https://issues.apache.org/jira/browse/TORQUE-165 > Project: Torque > Issue Type: Improvement >Reporter: Thomas Fox >Assignee: Thomas Fox > > If the flag criteria.cascade is set to true and a detelete() method is called > on a peer class, all rows ehich are referenced by the deleted rows should be > deleted as well, including rows which are referenced indirectly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-165) Implement cascading deletes
Implement cascading deletes --- Key: TORQUE-165 URL: https://issues.apache.org/jira/browse/TORQUE-165 Project: Torque Issue Type: Improvement Reporter: Thomas Fox If the flag criteria.cascade is set to true and a detelete() method is called on a peer class, all rows ehich are referenced by the deleted rows should be deleted as well, including rows which are referenced indirectly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-164) Fix foreign key storage in database map
Fix foreign key storage in database map --- Key: TORQUE-164 URL: https://issues.apache.org/jira/browse/TORQUE-164 Project: Torque Issue Type: Bug Components: Runtime, Templates Affects Versions: 3.3 Reporter: Thomas Fox Assignee: Thomas Fox Fix For: 4.0 Currently, the foreign key handling in the database map is suboptimal. It only supports columns which belong to zero or one foreign key. Columns which belong to several foreign keys are not supported. Also it is not possible to determine which foreign key columns belong to one foreign key in the case of composite foreign keys. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Reopened] (TORQUE-163) Map builders are emptied on Torque.shutdown() and not rebuilt on subsequent init()
[ https://issues.apache.org/jira/browse/TORQUE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox reopened TORQUE-163: --- In an exotic use case the problem exists. I have a normal TorqueInstance and init() and shutdown() it. Then I start a Avalon TorqueComponent. This component copies all registered Map builders from the normal TorqueInstance and rebuilds them. However, the previous shutdown on the TorqueInstance has emptied the map builder cache so the avalon component has no map builder components to build. Also the peer classes are all already loaded from previous usages so they will not register again to the avalon component. So the avalon component has an empty database map and will not work correctly. This exotic case happens when running the torque test project in eclipse. As a solution, I propose to not empty the map builder cache on shutdown. This will have no implication on normal init/shutdown cycles as the cached map builders know that they are built and will not build again, but will fix the above use case. > Map builders are emptied on Torque.shutdown() and not rebuilt on subsequent > init() > -- > > Key: TORQUE-163 > URL: https://issues.apache.org/jira/browse/TORQUE-163 > Project: Torque > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Thomas Fox >Assignee: Thomas Fox > > Problem: After a shutdown() and init() of Torque, the Map Builder cache > entries which have been present before shutdown are not present anymore after > a new init. > Analysis: If a Peer class is loaded, it registers its map builder and the > MapBuilder is built immediately or on Torque initialisation, depending on > whether Torque is initialized or not. > On Torque.shutdown(), all known map builders are removed. > On a new init(), these Map builders will not be rebuilt anew because the Peer > class will not be loaded a second time. > Solution: The Map Builder cache entries should not be removed on > Torque.shutdown() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
svn commit: r1147155 - /db/torque/torque4/trunk/torque-runtime/pom.xml
Author: tfischer Date: Fri Jul 15 13:56:52 2011 New Revision: 1147155 URL: http://svn.apache.org/viewvc?rev=1147155&view=rev Log: - update to newest java 1.5 compatible dbcp version - update to newest commons-lang version - remove direct dependency on commons-pool as we only have an indirect dependency through commons-dbcp Modified: db/torque/torque4/trunk/torque-runtime/pom.xml Modified: db/torque/torque4/trunk/torque-runtime/pom.xml URL: http://svn.apache.org/viewvc/db/torque/torque4/trunk/torque-runtime/pom.xml?rev=1147155&r1=1147154&r2=1147155&view=diff == --- db/torque/torque4/trunk/torque-runtime/pom.xml (original) +++ db/torque/torque4/trunk/torque-runtime/pom.xml Fri Jul 15 13:56:52 2011 @@ -78,13 +78,13 @@ commons-dbcp commons-dbcp - 1.2.2 + 1.3 commons-lang commons-lang - 2.3 + 2.6 @@ -100,12 +100,6 @@ - commons-pool - commons-pool - 1.3 - - - org.apache.jcs jcs 1.3 - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
