[jira] [Resolved] (TORQUE-359) All files are empty @ http://db.apache.org/torque/dtd/
[ https://issues.apache.org/jira/browse/TORQUE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-359. --- Resolution: Cannot Reproduce Assignee: Thomas Vandahl Fix Version/s: 4.1 The files may not display in the browser, however they download just fine. (Tried moments ago). If you use a browser to look at the files, try to the page source, that should do it. > All files are empty @ http://db.apache.org/torque/dtd/ > -- > > Key: TORQUE-359 > URL: https://issues.apache.org/jira/browse/TORQUE-359 > Project: Torque > Issue Type: Bug >Reporter: Scott Duchin >Assignee: Thomas Vandahl >Priority: Major > Fix For: 4.1 > > > we are using 3.2 torque but all the dtd files seem to be missing -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-357) Implement IDGenerator using java.sql.Statement.getGeneratedKeys
[ https://issues.apache.org/jira/browse/TORQUE-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-357. --- Resolution: Fixed Fix Version/s: 4.1 Added feature to read support from JDBC driver and use it if it exists. > Implement IDGenerator using java.sql.Statement.getGeneratedKeys > --- > > Key: TORQUE-357 > URL: https://issues.apache.org/jira/browse/TORQUE-357 > Project: Torque > Issue Type: New Feature > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Vandahl >Assignee: Thomas Vandahl >Priority: Major > Fix For: 4.1 > > > Avoid separate database roundtrip for JDBC drivers supporting > java.sql.Statement.getGeneratedKeys -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-357) Implement IDGenerator using java.sql.Statement.getGeneratedKeys
[ https://issues.apache.org/jira/browse/TORQUE-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl reassigned TORQUE-357: - Assignee: Thomas Vandahl > Implement IDGenerator using java.sql.Statement.getGeneratedKeys > --- > > Key: TORQUE-357 > URL: https://issues.apache.org/jira/browse/TORQUE-357 > Project: Torque > Issue Type: New Feature > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Vandahl >Assignee: Thomas Vandahl >Priority: Major > > Avoid separate database roundtrip for JDBC drivers supporting > java.sql.Statement.getGeneratedKeys -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-357) Implement IDGenerator using java.sql.Statement.getGeneratedKeys
Thomas Vandahl created TORQUE-357: - Summary: Implement IDGenerator using java.sql.Statement.getGeneratedKeys Key: TORQUE-357 URL: https://issues.apache.org/jira/browse/TORQUE-357 Project: Torque Issue Type: New Feature Components: Runtime Affects Versions: 4.0 Reporter: Thomas Vandahl Avoid separate database roundtrip for JDBC drivers supporting java.sql.Statement.getGeneratedKeys -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-356) Improve support for HSQLDB 2.x
Thomas Vandahl created TORQUE-356: - Summary: Improve support for HSQLDB 2.x Key: TORQUE-356 URL: https://issues.apache.org/jira/browse/TORQUE-356 Project: Torque Issue Type: Improvement Components: Runtime, Test Project Affects Versions: 4.0 Reporter: Thomas Vandahl Assignee: Thomas Vandahl Fix For: 4.1 HSQLDB Tests fail with HSQLDB 2.4.1. The following changes need to be made: * Remove special handling for ignoreCaseInOrderBy() * Add native limit/offset-support * Handle CURRENT_TIME returning timezone information -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-355) Implement millisecond support for MySQL timestamps
Thomas Vandahl created TORQUE-355: - Summary: Implement millisecond support for MySQL timestamps Key: TORQUE-355 URL: https://issues.apache.org/jira/browse/TORQUE-355 Project: Torque Issue Type: Improvement Components: Runtime, Templates, Test Project Affects Versions: 4.0 Environment: MySQL Reporter: Thomas Vandahl MySQL 5.6.4 and up expands fractional seconds support for TIME, DATETIME, and TIMESTAMP values, with up to microseconds (6 digits) precision. This needs to be supported. See https://dev.mysql.com/doc/refman/5.6/en/fractional-seconds.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-354) Add doSelectAsStream() to BasePeerImpl
Thomas Vandahl created TORQUE-354: - Summary: Add doSelectAsStream() to BasePeerImpl Key: TORQUE-354 URL: https://issues.apache.org/jira/browse/TORQUE-354 Project: Torque Issue Type: New Feature Components: Runtime Affects Versions: 4.0 Reporter: Thomas Vandahl Assignee: Thomas Vandahl Fix For: 4.1 Torque should support Java-8-style streaming of select-results. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-350) Make use of try-with-resources possible with Torque transactions
[ https://issues.apache.org/jira/browse/TORQUE-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-350. --- Resolution: Implemented Assignee: Thomas Vandahl I chose a wrapper instead of a proxy. TorqueException now extends SQLException! > Make use of try-with-resources possible with Torque transactions > > > Key: TORQUE-350 > URL: https://issues.apache.org/jira/browse/TORQUE-350 > Project: Torque > Issue Type: Improvement > Components: Runtime, Templates >Affects Versions: 4.0 >Reporter: Thomas Vandahl >Assignee: Thomas Vandahl >Priority: Major > Fix For: 4.1 > > > We use the java.sql.Connection to wrap database operations into transactions. > As of Java7, Connection is AutoCloseable. I propose to introduce a dynamic > proxy to catch the close call and implement the pattern as described in > https://db.apache.org/torque/torque-4.0/documentation/orm-reference/connections-transactions.html > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-348) Why is the databases-map not cleared during shutdown?
[ https://issues.apache.org/jira/browse/TORQUE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-348. --- Resolution: Not A Problem Assignee: Thomas Vandahl Fix Version/s: 4.1 Obviously not. > Why is the databases-map not cleared during shutdown? > - > > Key: TORQUE-348 > URL: https://issues.apache.org/jira/browse/TORQUE-348 > Project: Torque > Issue Type: Bug > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Vandahl >Assignee: Thomas Vandahl >Priority: Major > Fix For: 4.1 > > > There has been made quite some effort to close the DataSourceFactories when > shutting down Torque. However the databases map still contains all database > instances. There is even a test to prove that is the case. Does this actually > make sense? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Issue Comment Deleted] (TORQUE-351) Torque-Generator, runOnlyOnSourceChange
[
https://issues.apache.org/jira/browse/TORQUE-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl updated TORQUE-351:
--
Comment: was deleted
(was: The Mac file system only has second resolution, so this fix doesn't help.)
> Torque-Generator, runOnlyOnSourceChange
> ---
>
> Key: TORQUE-351
> URL: https://issues.apache.org/jira/browse/TORQUE-351
> Project: Torque
> Issue Type: Bug
> Components: Generator
>Affects Versions: 4.1
> Environment: Apache Maven 3.5.3
> (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> ..
> Java version: 1.8.0_171, vendor: Oracle Corporation
> Java home: C:\java\jdk8x64\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Georg Kallidis
>Assignee: Thomas Vandahl
>Priority: Major
> Fix For: 4.1
>
>
> I get an test failure in torque-generator running mvn clean test:
>
> {code:java}
> Test set: org.apache.torque.generator.control.RunOnlyOnSourceChangeTest
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.14 sec <<<
> FAILURE!
> testRunOnlyOnSourceChange(org.apache.torque.generator.control.RunOnlyOnSourceChangeTest)
> Time elapsed: 1.14 sec <<< FAILURE!
> java.lang.AssertionError: Tue Jul 03 11:13:31 CEST 2018 not equal to Tue Jul
> 03 11:13:32 CEST 2018 expected:<1530609211675> but was:<1530609212737>
> at org.junit.Assert.fail(Assert.java:91)
> at org.junit.Assert.failNotEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:126)
> at org.junit.Assert.assertEquals(Assert.java:470)
> at
> org.apache.torque.generator.control.RunOnlyOnSourceChangeTest.testRunOnlyOnSourceChange(RunOnlyOnSourceChangeTest.java:112)
> {code}
> It fails at this line (the first teste after initialization and the content
> was moved)
>
>
> {code:java}
> assertTrue(unchangedTargetFile1LastModified == assertFile(targetDir1,
> "unchangedOutput.txt", "unchangedValue"));
> {code}
>
> Apparently unchangedOutput.txt should not have changed the lastModified
> (I expanded the assert to get a little more information.) The reported time
> difference (about 1000msec) is due to
> {code:java}
> Thread.sleep(1000);
> {code}
> in the test and is apparently only there because checkSourceModified returns
> true (I read TORQUE-338, this might be also still another issue), i.e. it's
> not the reason, why itt fails, but a consequence of it.
> Investigating the source code I found, that, if I comment out this
>
> {code:java}
> if (lastGenerationTime.before(sourceLastModified))
> {
> log.debug("checkSourceModified(): "
> + "lastGenerationTime was before source was modified ("
> + lastGenerationTime
> + " < "
> + sourceLastModified
> + "), return true");
> sourceModifiedCache.put(sourceChangeKey, true);
> return true;
> }
> {code}
> in
> {noformat}
> org.apache.torque.generator.control.Controller.checkSourceModified(Source,
> ControllerState, UnitConfiguration){noformat}
> which is called, if _isRunOnlyOnSourceChange_ is true for the
> unitConfiguration, the failure is gone.
> The time difference there between lastGenerationTime and sourceLastModified
> is alwasy below 100ms (sometimes only 25ms), and might be due to the OS
> environment. This might be a windows problem? One solution might be to remove
> the milliseconds.
> If I replace the code with
> {code:java}
> final GregorianCalendar gcLastGenerationTime = new GregorianCalendar();
> gcLastGenerationTime.setTime( lastGenerationTime );
> gcLastGenerationTime.set(Calendar.MILLISECOND, 0);
> final GregorianCalendar gcSourceLastModified = new GregorianCalendar();
> gcSourceLastModified.setTime( sourceLastModified );
> gcSourceLastModified.set(Calendar.MILLISECOND, 0);
> if (gcLastGenerationTime.before(gcSourceLastModified))
> {code}
> all the tests run successfully.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-351) Torque-Generator, runOnlyOnSourceChange
[
https://issues.apache.org/jira/browse/TORQUE-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved TORQUE-351.
---
Resolution: Fixed
Assignee: Thomas Vandahl
Fix Version/s: 4.1
Fixed in SVN
> Torque-Generator, runOnlyOnSourceChange
> ---
>
> Key: TORQUE-351
> URL: https://issues.apache.org/jira/browse/TORQUE-351
> Project: Torque
> Issue Type: Bug
> Components: Generator
>Affects Versions: 4.1
> Environment: Apache Maven 3.5.3
> (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> ..
> Java version: 1.8.0_171, vendor: Oracle Corporation
> Java home: C:\java\jdk8x64\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Georg Kallidis
>Assignee: Thomas Vandahl
>Priority: Major
> Fix For: 4.1
>
>
> I get an test failure in torque-generator running mvn clean test:
>
> {code:java}
> Test set: org.apache.torque.generator.control.RunOnlyOnSourceChangeTest
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.14 sec <<<
> FAILURE!
> testRunOnlyOnSourceChange(org.apache.torque.generator.control.RunOnlyOnSourceChangeTest)
> Time elapsed: 1.14 sec <<< FAILURE!
> java.lang.AssertionError: Tue Jul 03 11:13:31 CEST 2018 not equal to Tue Jul
> 03 11:13:32 CEST 2018 expected:<1530609211675> but was:<1530609212737>
> at org.junit.Assert.fail(Assert.java:91)
> at org.junit.Assert.failNotEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:126)
> at org.junit.Assert.assertEquals(Assert.java:470)
> at
> org.apache.torque.generator.control.RunOnlyOnSourceChangeTest.testRunOnlyOnSourceChange(RunOnlyOnSourceChangeTest.java:112)
> {code}
> It fails at this line (the first teste after initialization and the content
> was moved)
>
>
> {code:java}
> assertTrue(unchangedTargetFile1LastModified == assertFile(targetDir1,
> "unchangedOutput.txt", "unchangedValue"));
> {code}
>
> Apparently unchangedOutput.txt should not have changed the lastModified
> (I expanded the assert to get a little more information.) The reported time
> difference (about 1000msec) is due to
> {code:java}
> Thread.sleep(1000);
> {code}
> in the test and is apparently only there because checkSourceModified returns
> true (I read TORQUE-338, this might be also still another issue), i.e. it's
> not the reason, why itt fails, but a consequence of it.
> Investigating the source code I found, that, if I comment out this
>
> {code:java}
> if (lastGenerationTime.before(sourceLastModified))
> {
> log.debug("checkSourceModified(): "
> + "lastGenerationTime was before source was modified ("
> + lastGenerationTime
> + " < "
> + sourceLastModified
> + "), return true");
> sourceModifiedCache.put(sourceChangeKey, true);
> return true;
> }
> {code}
> in
> {noformat}
> org.apache.torque.generator.control.Controller.checkSourceModified(Source,
> ControllerState, UnitConfiguration){noformat}
> which is called, if _isRunOnlyOnSourceChange_ is true for the
> unitConfiguration, the failure is gone.
> The time difference there between lastGenerationTime and sourceLastModified
> is alwasy below 100ms (sometimes only 25ms), and might be due to the OS
> environment. This might be a windows problem? One solution might be to remove
> the milliseconds.
> If I replace the code with
> {code:java}
> final GregorianCalendar gcLastGenerationTime = new GregorianCalendar();
> gcLastGenerationTime.setTime( lastGenerationTime );
> gcLastGenerationTime.set(Calendar.MILLISECOND, 0);
> final GregorianCalendar gcSourceLastModified = new GregorianCalendar();
> gcSourceLastModified.setTime( sourceLastModified );
> gcSourceLastModified.set(Calendar.MILLISECOND, 0);
> if (gcLastGenerationTime.before(gcSourceLastModified))
> {code}
> all the tests run successfully.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-351) Torque-Generator, runOnlyOnSourceChange
[
https://issues.apache.org/jira/browse/TORQUE-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16592907#comment-16592907
]
Thomas Vandahl commented on TORQUE-351:
---
The test relies on the *identical* timestamps of two sets of files in
torque-generator/src/test/runOnlyOnSourceChange/src/main/torque-gen/src and
torque-generator/src/test/runOnlyOnSourceChange/src/main/torque-gen/secondSource
This is a bad assumption as in default svn, use-commit-times is set to "no"
and timestamps can differ when checking out the code.
If I synchronize the timestamps of the files in the two directories, the test
passes, even with the original code. I'll add that to the test code.
> Torque-Generator, runOnlyOnSourceChange
> ---
>
> Key: TORQUE-351
> URL: https://issues.apache.org/jira/browse/TORQUE-351
> Project: Torque
> Issue Type: Bug
> Components: Generator
>Affects Versions: 4.1
> Environment: Apache Maven 3.5.3
> (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> ..
> Java version: 1.8.0_171, vendor: Oracle Corporation
> Java home: C:\java\jdk8x64\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Georg Kallidis
>Priority: Major
>
> I get an test failure in torque-generator running mvn clean test:
>
> {code:java}
> Test set: org.apache.torque.generator.control.RunOnlyOnSourceChangeTest
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.14 sec <<<
> FAILURE!
> testRunOnlyOnSourceChange(org.apache.torque.generator.control.RunOnlyOnSourceChangeTest)
> Time elapsed: 1.14 sec <<< FAILURE!
> java.lang.AssertionError: Tue Jul 03 11:13:31 CEST 2018 not equal to Tue Jul
> 03 11:13:32 CEST 2018 expected:<1530609211675> but was:<1530609212737>
> at org.junit.Assert.fail(Assert.java:91)
> at org.junit.Assert.failNotEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:126)
> at org.junit.Assert.assertEquals(Assert.java:470)
> at
> org.apache.torque.generator.control.RunOnlyOnSourceChangeTest.testRunOnlyOnSourceChange(RunOnlyOnSourceChangeTest.java:112)
> {code}
> It fails at this line (the first teste after initialization and the content
> was moved)
>
>
> {code:java}
> assertTrue(unchangedTargetFile1LastModified == assertFile(targetDir1,
> "unchangedOutput.txt", "unchangedValue"));
> {code}
>
> Apparently unchangedOutput.txt should not have changed the lastModified
> (I expanded the assert to get a little more information.) The reported time
> difference (about 1000msec) is due to
> {code:java}
> Thread.sleep(1000);
> {code}
> in the test and is apparently only there because checkSourceModified returns
> true (I read TORQUE-338, this might be also still another issue), i.e. it's
> not the reason, why itt fails, but a consequence of it.
> Investigating the source code I found, that, if I comment out this
>
> {code:java}
> if (lastGenerationTime.before(sourceLastModified))
> {
> log.debug("checkSourceModified(): "
> + "lastGenerationTime was before source was modified ("
> + lastGenerationTime
> + " < "
> + sourceLastModified
> + "), return true");
> sourceModifiedCache.put(sourceChangeKey, true);
> return true;
> }
> {code}
> in
> {noformat}
> org.apache.torque.generator.control.Controller.checkSourceModified(Source,
> ControllerState, UnitConfiguration){noformat}
> which is called, if _isRunOnlyOnSourceChange_ is true for the
> unitConfiguration, the failure is gone.
> The time difference there between lastGenerationTime and sourceLastModified
> is alwasy below 100ms (sometimes only 25ms), and might be due to the OS
> environment. This might be a windows problem? One solution might be to remove
> the milliseconds.
> If I replace the code with
> {code:java}
> final GregorianCalendar gcLastGenerationTime = new GregorianCalendar();
> gcLastGenerationTime.setTime( lastGenerationTime );
> gcLastGenerationTime.set(Calendar.MILLISECOND, 0);
> final GregorianCalendar gcSourceLastModified = new GregorianCalendar();
> gcSourceLastModified.setTime( sourceLastModified );
> gcSourceLastModified.set(Calendar.MILLISECOND, 0);
> if (gcLastGenerationTime.before(gcSourceLastModified))
> {code}
> all the tests run successfully.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Updated] (TORQUE-353) DataTest.testLikeClauseEscaping fails on MySQL 5.7.16
[
https://issues.apache.org/jira/browse/TORQUE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl updated TORQUE-353:
--
Description:
MySQL 5.7.16 on Mac OS X 10.11.6
DataTest.testLikeClauseEscaping tests if '%c' matches 'a\c' which fails.
This is actually a MySQL problem which can be reproduced on the command line:
{code:sql}
mysql> select * from Author;
+---+--+
| author_id | name |
+---+--+
| 1728 | abc |
| 1729 | bbc |
| 1730 | a_c |
| 1731 | a%c |
| 1732 | a\c |
| 1733 | a"c |
| 1734 | a'c |
| 1735 | a?c |
| 1736 | a*c |
+---+--+
9 rows in set (0,00 sec)
mysql> select * from Author where name like '%c';
Empty set (0,00 sec)
{code}
Strangely enough, the following succeeds:
{code:sql}
mysql> select * from Author where name like '%\\c';
+---+--+
| author_id | name |
+---+--+
| 1732 | a\c |
+---+--+
1 row in set (0,00 sec)
{code}
Any idea how to handle this?
was:
MySQL 5.7.16 on Mac OS X 10.11.6
DataTest.testLikeClauseEscaping tests if '%\\c' matches 'a\c' which fails.
This is actually a MySQL problem which can be reproduced on the command line:
{code:java}
mysql> select * from Author;
+---+--+
| author_id | name |
+---+--+
| 1728 | abc |
| 1729 | bbc |
| 1730 | a_c |
| 1731 | a%c |
| 1732 | a\c |
| 1733 | a"c |
| 1734 | a'c |
| 1735 | a?c |
| 1736 | a*c |
+---+--+
9 rows in set (0,00 sec)
mysql> select * from Author where name like '%c';
Empty set (0,00 sec)
{code}
Strangely enough, the following succeeds:
{code:java}
mysql> select * from Author where name like '%\\c';
+---+--+
| author_id | name |
+---+--+
| 1732 | a\c |
+---+--+
1 row in set (0,00 sec)
{code}
Any idea how to handle this?
> DataTest.testLikeClauseEscaping fails on MySQL 5.7.16
> -
>
> Key: TORQUE-353
> URL: https://issues.apache.org/jira/browse/TORQUE-353
> Project: Torque
> Issue Type: Bug
> Components: Runtime, Test Project
>Affects Versions: 4.1
>Reporter: Thomas Vandahl
>Priority: Major
>
> MySQL 5.7.16 on Mac OS X 10.11.6
> DataTest.testLikeClauseEscaping tests if '%c' matches 'a\c' which fails.
> This is actually a MySQL problem which can be reproduced on the command line:
> {code:sql}
> mysql> select * from Author;
> +---+--+
> | author_id | name |
> +---+--+
> | 1728 | abc |
> | 1729 | bbc |
> | 1730 | a_c |
> | 1731 | a%c |
> | 1732 | a\c |
> | 1733 | a"c |
> | 1734 | a'c |
> | 1735 | a?c |
> | 1736 | a*c |
> +---+--+
> 9 rows in set (0,00 sec)
> mysql> select * from Author where name like '%c';
> Empty set (0,00 sec)
> {code}
> Strangely enough, the following succeeds:
> {code:sql}
> mysql> select * from Author where name like '%\\c';
> +---+--+
> | author_id | name |
> +---+--+
> | 1732 | a\c |
> +---+--+
> 1 row in set (0,00 sec)
> {code}
> Any idea how to handle this?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Updated] (TORQUE-353) DataTest.testLikeClauseEscaping fails on MySQL 5.7.16
[
https://issues.apache.org/jira/browse/TORQUE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl updated TORQUE-353:
--
Description:
MySQL 5.7.16 on Mac OS X 10.11.6
DataTest.testLikeClauseEscaping tests if '%\\c' matches 'a\c' which fails.
This is actually a MySQL problem which can be reproduced on the command line:
{code:java}
mysql> select * from Author;
+---+--+
| author_id | name |
+---+--+
| 1728 | abc |
| 1729 | bbc |
| 1730 | a_c |
| 1731 | a%c |
| 1732 | a\c |
| 1733 | a"c |
| 1734 | a'c |
| 1735 | a?c |
| 1736 | a*c |
+---+--+
9 rows in set (0,00 sec)
mysql> select * from Author where name like '%c';
Empty set (0,00 sec)
{code}
Strangely enough, the following succeeds:
{code:java}
mysql> select * from Author where name like '%\\c';
+---+--+
| author_id | name |
+---+--+
| 1732 | a\c |
+---+--+
1 row in set (0,00 sec)
{code}
Any idea how to handle this?
was:
MySQL 5.7.16 on Mac OS X 10.11.6
DataTest.testLikeClauseEscaping tests if '%\\c' matches 'a\\c' which fails.
This is actually a MySQL problem which can be reproduced on the command line:
{code:java}
mysql> select * from Author;
+---+--+
| author_id | name |
+---+--+
| 1728 | abc |
| 1729 | bbc |
| 1730 | a_c |
| 1731 | a%c |
| 1732 | a\c |
| 1733 | a"c |
| 1734 | a'c |
| 1735 | a?c |
| 1736 | a*c |
+---+--+
9 rows in set (0,00 sec)
mysql> select * from Author where name like '%c';
Empty set (0,00 sec)
{code}
Strangely enough, the following succeeds:
{code:java}
mysql> select * from Author where name like '%\\c';
+---+--+
| author_id | name |
+---+--+
| 1732 | a\c |
+---+--+
1 row in set (0,00 sec)
{code}
Any idea how to handle this?
> DataTest.testLikeClauseEscaping fails on MySQL 5.7.16
> -
>
> Key: TORQUE-353
> URL: https://issues.apache.org/jira/browse/TORQUE-353
> Project: Torque
> Issue Type: Bug
> Components: Runtime, Test Project
>Affects Versions: 4.1
>Reporter: Thomas Vandahl
>Priority: Major
>
> MySQL 5.7.16 on Mac OS X 10.11.6
> DataTest.testLikeClauseEscaping tests if '%\\c' matches 'a\c' which fails.
> This is actually a MySQL problem which can be reproduced on the command line:
> {code:java}
> mysql> select * from Author;
> +---+--+
> | author_id | name |
> +---+--+
> | 1728 | abc |
> | 1729 | bbc |
> | 1730 | a_c |
> | 1731 | a%c |
> | 1732 | a\c |
> | 1733 | a"c |
> | 1734 | a'c |
> | 1735 | a?c |
> | 1736 | a*c |
> +---+--+
> 9 rows in set (0,00 sec)
> mysql> select * from Author where name like '%c';
> Empty set (0,00 sec)
> {code}
> Strangely enough, the following succeeds:
> {code:java}
> mysql> select * from Author where name like '%\\c';
> +---+--+
> | author_id | name |
> +---+--+
> | 1732 | a\c |
> +---+--+
> 1 row in set (0,00 sec)
> {code}
> Any idea how to handle this?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-353) DataTest.testLikeClauseEscaping fails on MySQL 5.7.16
Thomas Vandahl created TORQUE-353:
-
Summary: DataTest.testLikeClauseEscaping fails on MySQL 5.7.16
Key: TORQUE-353
URL: https://issues.apache.org/jira/browse/TORQUE-353
Project: Torque
Issue Type: Bug
Components: Runtime, Test Project
Affects Versions: 4.1
Reporter: Thomas Vandahl
MySQL 5.7.16 on Mac OS X 10.11.6
DataTest.testLikeClauseEscaping tests if '%\\c' matches 'a\\c' which fails.
This is actually a MySQL problem which can be reproduced on the command line:
{code:java}
mysql> select * from Author;
+---+--+
| author_id | name |
+---+--+
| 1728 | abc |
| 1729 | bbc |
| 1730 | a_c |
| 1731 | a%c |
| 1732 | a\c |
| 1733 | a"c |
| 1734 | a'c |
| 1735 | a?c |
| 1736 | a*c |
+---+--+
9 rows in set (0,00 sec)
mysql> select * from Author where name like '%c';
Empty set (0,00 sec)
{code}
Strangely enough, the following succeeds:
{code:java}
mysql> select * from Author where name like '%\\c';
+---+--+
| author_id | name |
+---+--+
| 1732 | a\c |
+---+--+
1 row in set (0,00 sec)
{code}
Any idea how to handle this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-349) Runtime Exception during server startup - java.lang.RuntimeException (org.apache.torque.TorqueException: java.lang.ArrayIndexOutOfBoundsException)
[ https://issues.apache.org/jira/browse/TORQUE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-349. --- Resolution: Won't Fix Assignee: Thomas Vandahl Please try again with Torque 4.0 > Runtime Exception during server startup - java.lang.RuntimeException > (org.apache.torque.TorqueException: java.lang.ArrayIndexOutOfBoundsException) > -- > > Key: TORQUE-349 > URL: https://issues.apache.org/jira/browse/TORQUE-349 > Project: Torque > Issue Type: Bug > Components: Runtime >Affects Versions: 3.3-RC2 > Environment: Tomcat 8/jdk 8 - Production environment >Reporter: Ramesh Uppalapati >Assignee: Thomas Vandahl >Priority: Major > > Getting ArrayIndexOutOfBoundsException on initial server startup in all > instances. Below is the stack trace of the logs. Please help me I was unable > to solve the issue after various debugs. > Maven Config > > > org.apache.db.torque > runtime > 3.3-RC2 > > 08/30/16 11:35:20 [ConfigReinitDaemon] ERROR > com.exostar.config.DbConfigLoader:Reload() excp: > java.lang.RuntimeException: org.apache.torque.TorqueException: > java.lang.ArrayIndexOutOfBoundsException: 122 >at > com.exostar.config.DbConfigLoader.buildMaps(DbConfigLoader.java:184) >at > com.exostar.config.DbConfigLoader.Reload(DbConfigLoader.java:136) >at > com.evincible.config.ConfigLoader.reloadAll(ConfigLoader.java:284) >at > com.evincible.config.ConfigLoader.reloadAllAndReinit(ConfigLoader.java:374) >at > com.evincible.config.ConfigLoader.checkReload(ConfigLoader.java:381) >at > com.evincible.config.ConfigReinitDaemon$ReloadWorker.run(ConfigReinitDaemon.java:74) >at java.util.TimerThread.mainLoop(Timer.java:555) >at java.util.TimerThread.run(Timer.java:505) > Caused by: org.apache.torque.TorqueException: > java.lang.ArrayIndexOutOfBoundsException: 122 >at > org.apache.torque.util.BasePeer.throwTorqueException(BasePeer.java:105) >at > org.apache.torque.util.BasePeer.getSelectResults(BasePeer.java:1024) >at > org.apache.torque.util.BasePeer.executeQuery(BasePeer.java:887) >at org.apache.torque.util.BasePeer.doSelect(BasePeer.java:734) >at org.apache.torque.util.BasePeer.doSelect(BasePeer.java:707) >at > com.exostar.config.om.base.BaseConfigItemPeer.doSelectVillageRecords(BaseConfigItemPeer.java:396) >at > com.exostar.config.om.base.BaseConfigItemPeer.doSelectVillageRecords(BaseConfigItemPeer.java:369) >at > com.exostar.config.om.base.BaseConfigItemPeer.doSelect(BaseConfigItemPeer.java:337) >at > com.exostar.config.om.base.BaseConfigBean.getConfigItems(BaseConfigBean.java:386) >at > com.exostar.config.om.base.BaseConfigBean.getConfigItems(BaseConfigBean.java:359) >at > com.exostar.config.DbConfigLoader.buildMaps(DbConfigLoader.java:177) >... 7 more > Caused by: java.lang.ArrayIndexOutOfBoundsException: 122 >at net.sourceforge.jtds.jdbc.TdsData.readData(TdsData.java:825) >at > net.sourceforge.jtds.jdbc.TdsCore.tdsRowToken(TdsCore.java:3175) >at > net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2433) >at > net.sourceforge.jtds.jdbc.TdsCore.getNextRow(TdsCore.java:805) >at > net.sourceforge.jtds.jdbc.JtdsResultSet.next(JtdsResultSet.java:611) >at > com.workingdogs.village.DataSet.fetchRecords(DataSet.java:604) >at > com.workingdogs.village.DataSet.fetchRecords(DataSet.java:540) >at > com.workingdogs.village.DataSet.fetchRecords(DataSet.java:524) >at > org.apache.torque.util.BasePeer.getSelectResults(BasePeer.java:994) >... 16 more -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-351) Torque-Generator, runOnlyOnSourceChange
[
https://issues.apache.org/jira/browse/TORQUE-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582362#comment-16582362
]
Thomas Vandahl commented on TORQUE-351:
---
The Mac file system only has second resolution, so this fix doesn't help.
> Torque-Generator, runOnlyOnSourceChange
> ---
>
> Key: TORQUE-351
> URL: https://issues.apache.org/jira/browse/TORQUE-351
> Project: Torque
> Issue Type: Bug
> Components: Generator
>Affects Versions: 4.1
> Environment: Apache Maven 3.5.3
> (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> ..
> Java version: 1.8.0_171, vendor: Oracle Corporation
> Java home: C:\java\jdk8x64\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Georg Kallidis
>Priority: Major
>
> I get an test failure in torque-generator running mvn clean test:
>
> {code:java}
> Test set: org.apache.torque.generator.control.RunOnlyOnSourceChangeTest
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.14 sec <<<
> FAILURE!
> testRunOnlyOnSourceChange(org.apache.torque.generator.control.RunOnlyOnSourceChangeTest)
> Time elapsed: 1.14 sec <<< FAILURE!
> java.lang.AssertionError: Tue Jul 03 11:13:31 CEST 2018 not equal to Tue Jul
> 03 11:13:32 CEST 2018 expected:<1530609211675> but was:<1530609212737>
> at org.junit.Assert.fail(Assert.java:91)
> at org.junit.Assert.failNotEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:126)
> at org.junit.Assert.assertEquals(Assert.java:470)
> at
> org.apache.torque.generator.control.RunOnlyOnSourceChangeTest.testRunOnlyOnSourceChange(RunOnlyOnSourceChangeTest.java:112)
> {code}
> It fails at this line (the first teste after initialization and the content
> was moved)
>
>
> {code:java}
> assertTrue(unchangedTargetFile1LastModified == assertFile(targetDir1,
> "unchangedOutput.txt", "unchangedValue"));
> {code}
>
> Apparently unchangedOutput.txt should not have changed the lastModified
> (I expanded the assert to get a little more information.) The reported time
> difference (about 1000msec) is due to
> {code:java}
> Thread.sleep(1000);
> {code}
> in the test and is apparently only there because checkSourceModified returns
> true (I read TORQUE-338, this might be also still another issue), i.e. it's
> not the reason, why itt fails, but a consequence of it.
> Investigating the source code I found, that, if I comment out this
>
> {code:java}
> if (lastGenerationTime.before(sourceLastModified))
> {
> log.debug("checkSourceModified(): "
> + "lastGenerationTime was before source was modified ("
> + lastGenerationTime
> + " < "
> + sourceLastModified
> + "), return true");
> sourceModifiedCache.put(sourceChangeKey, true);
> return true;
> }
> {code}
> in
> {noformat}
> org.apache.torque.generator.control.Controller.checkSourceModified(Source,
> ControllerState, UnitConfiguration){noformat}
> which is called, if _isRunOnlyOnSourceChange_ is true for the
> unitConfiguration, the failure is gone.
> The time difference there between lastGenerationTime and sourceLastModified
> is alwasy below 100ms (sometimes only 25ms), and might be due to the OS
> environment. This might be a windows problem? One solution might be to remove
> the milliseconds.
> If I replace the code with
> {code:java}
> final GregorianCalendar gcLastGenerationTime = new GregorianCalendar();
> gcLastGenerationTime.setTime( lastGenerationTime );
> gcLastGenerationTime.set(Calendar.MILLISECOND, 0);
> final GregorianCalendar gcSourceLastModified = new GregorianCalendar();
> gcSourceLastModified.setTime( sourceLastModified );
> gcSourceLastModified.set(Calendar.MILLISECOND, 0);
> if (gcLastGenerationTime.before(gcSourceLastModified))
> {code}
> all the tests run successfully.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (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:all-tabpanel
]
Thomas Vandahl resolved TORQUE-343.
---
Resolution: Fixed
> 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] [Resolved] (TORQUE-347) Reduce the amount of synchronization in collections used by Torque
[ https://issues.apache.org/jira/browse/TORQUE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-347. --- Resolution: Fixed Fixed most cases > Reduce the amount of synchronization in collections used by Torque > -- > > Key: TORQUE-347 > URL: https://issues.apache.org/jira/browse/TORQUE-347 > Project: Torque > Issue Type: Improvement > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Vandahl >Assignee: Thomas Vandahl > Fix For: 4.1 > > > Torque makes use of Collections.synchronizedMap() in several places where > ConcurrentMaps should be used. > Namely: > * TorqueInstance.databases > * (TorqueInstance.managers) > * ColumnMap.inheritanceMaps > * ColumnMap.optionsMap > * DatabaseMap.tables > * DatabaseMap.optionsMap > * TableMap.columns > * TableMap.optionsMap -- 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-347) Reduce the amount of synchronization in collections used by Torque
[ https://issues.apache.org/jira/browse/TORQUE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15479624#comment-15479624 ] Thomas Vandahl commented on TORQUE-347: --- [~tfischer]: Why are ColumnMap.inheritanceMaps, DatabaseMap.tables and TableMap.columns synchronized and how are they actually used in the runtime? I see no real reason to keep the XML order outside the generator scope. Am I mistaken? > Reduce the amount of synchronization in collections used by Torque > -- > > Key: TORQUE-347 > URL: https://issues.apache.org/jira/browse/TORQUE-347 > Project: Torque > Issue Type: Improvement > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Vandahl >Assignee: Thomas Vandahl > Fix For: 4.1 > > > Torque makes use of Collections.synchronizedMap() in several places where > ConcurrentMaps should be used. > Namely: > * TorqueInstance.databases > * (TorqueInstance.managers) > * ColumnMap.inheritanceMaps > * ColumnMap.optionsMap > * DatabaseMap.tables > * DatabaseMap.optionsMap > * TableMap.columns > * TableMap.optionsMap -- 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] [Created] (TORQUE-350) Make use of try-with-resources possible with Torque transactions
Thomas Vandahl created TORQUE-350: - Summary: Make use of try-with-resources possible with Torque transactions Key: TORQUE-350 URL: https://issues.apache.org/jira/browse/TORQUE-350 Project: Torque Issue Type: Improvement Components: Runtime, Templates Affects Versions: 4.0 Reporter: Thomas Vandahl Fix For: 4.1 We use the java.sql.Connection to wrap database operations into transactions. As of Java7, Connection is AutoCloseable. I propose to introduce a dynamic proxy to catch the close call and implement the pattern as described in https://db.apache.org/torque/torque-4.0/documentation/orm-reference/connections-transactions.html -- 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=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] [Created] (TORQUE-348) Why is the databases-map not cleared during shutdown?
Thomas Vandahl created TORQUE-348: - Summary: Why is the databases-map not cleared during shutdown? Key: TORQUE-348 URL: https://issues.apache.org/jira/browse/TORQUE-348 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 4.0 Reporter: Thomas Vandahl There has been made quite some effort to close the DataSourceFactories when shutting down Torque. However the databases map still contains all database instances. There is even a test to prove that is the case. Does this actually make sense? -- 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] [Created] (TORQUE-347) Reduce the amount of synchronization in collections used by Torque
Thomas Vandahl created TORQUE-347: - Summary: Reduce the amount of synchronization in collections used by Torque Key: TORQUE-347 URL: https://issues.apache.org/jira/browse/TORQUE-347 Project: Torque Issue Type: Improvement Components: Runtime Affects Versions: 4.0 Reporter: Thomas Vandahl Assignee: Thomas Vandahl Fix For: 4.1 Torque makes use of Collections.synchronizedMap() in several places where ConcurrentMaps should be used. Namely: * TorqueInstance.databases * (TorqueInstance.managers) * ColumnMap.inheritanceMaps * ColumnMap.optionsMap * DatabaseMap.tables * DatabaseMap.optionsMap * TableMap.columns * TableMap.optionsMap -- 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] [Resolved] (TORQUE-346) Introduce abstract layer for peer impl to reduce the amount of generated code
[ https://issues.apache.org/jira/browse/TORQUE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-346. --- Resolution: Fixed Fixed in SVN > 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-346) Introduce abstract layer for peer impl to reduce the amount of generated code
[ https://issues.apache.org/jira/browse/TORQUE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15395587#comment-15395587 ] Thomas Vandahl commented on TORQUE-346: --- [~tfischer]: Another question: Is obj.getPrimaryKey() != null a valid method to check for the availability of a primary key at runtime? If so, I could make the decision what to use within buildCriteria(obj) and get rid of buildCriteria(pk). > 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
[
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-346) Introduce abstract layer for peer impl to reduce the amount of generated code
[ https://issues.apache.org/jira/browse/TORQUE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15394360#comment-15394360 ] Thomas Vandahl commented on TORQUE-346: --- [~tfischer]: Question: What is the actual meaning of "torque.om.trackDeleted"? It seems not to be documented. > 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] [Created] (TORQUE-346) Introduce abstract layer for peer impl to reduce the amount of generated code
Thomas Vandahl created TORQUE-346: - Summary: 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] [Resolved] (TORQUE-345) Remove commons-collections dependency
[ https://issues.apache.org/jira/browse/TORQUE-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-345. --- Resolution: Fixed Fixed in SVN > Remove commons-collections dependency > - > > Key: TORQUE-345 > URL: https://issues.apache.org/jira/browse/TORQUE-345 > Project: Torque > Issue Type: Improvement > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Vandahl >Assignee: Thomas Vandahl >Priority: Minor > Fix For: 4.1 > > > ListOrderedMapCI and SummaryHelper draw in classes from commons-collections > which can be replaced by JDK native ones. -- 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] [Created] (TORQUE-345) Remove commons-collections dependency
Thomas Vandahl created TORQUE-345: - Summary: Remove commons-collections dependency Key: TORQUE-345 URL: https://issues.apache.org/jira/browse/TORQUE-345 Project: Torque Issue Type: Improvement Components: Runtime Affects Versions: 4.0 Reporter: Thomas Vandahl Assignee: Thomas Vandahl Priority: Minor Fix For: 4.1 ListOrderedMapCI and SummaryHelper draw in classes from commons-collections which can be replaced by JDK native ones. -- 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] [Resolved] (TORQUE-344) Update to Commons Pool/DBCP Version 2
[
https://issues.apache.org/jira/browse/TORQUE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved TORQUE-344.
---
Resolution: Fixed
Fix Version/s: 4.1
Added PerUserPool2DataSourceFactory.java and SharedPool2DataSourceFactory.java.
Made both dbcp-dependencies optional.
> Update to Commons Pool/DBCP Version 2
> -
>
> Key: TORQUE-344
> URL: https://issues.apache.org/jira/browse/TORQUE-344
> Project: Torque
> Issue Type: Improvement
> Components: Runtime
>Affects Versions: 4.1
>Reporter: Georg Kallidis
>Assignee: Thomas Vandahl
> Fix For: 4.1
>
>
> Support for Apache Commons Pool Version 2 (since 2013, current verson 2.4.2)
> and Apache Commons DBCP2 features (since 2014, current version 2.1.1).
> Caveat: Commons Pool 2 requires Java 1.6, but DBCP 2 Java 1.7.
> Code changes seem to be minimal in only a few dsfactory classes. Maybe the
> easiest way to support version 2 pool/dbcp is to allow for another module
> runtime2 with appropriate dependencies?
> e.g. ...
>
> org.apache.torque
> torque-runtime
> ${project.version}
>
>
> commons-dbcp
> commons-dbcp
>
>
>
>
> org.apache.commons
> commons-dbcp2
> 2.1.1
>
--
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-344) Update to Commons Pool/DBCP Version 2
[
https://issues.apache.org/jira/browse/TORQUE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15394032#comment-15394032
]
Thomas Vandahl commented on TORQUE-344:
---
I'd rather make both dependencies optional and document this accordingly. I'll
try to fiddle something with a maven profile.
> Update to Commons Pool/DBCP Version 2
> -
>
> Key: TORQUE-344
> URL: https://issues.apache.org/jira/browse/TORQUE-344
> Project: Torque
> Issue Type: Improvement
> Components: Runtime
>Affects Versions: 4.1
>Reporter: Georg Kallidis
>Assignee: Thomas Vandahl
>
> Support for Apache Commons Pool Version 2 (since 2013, current verson 2.4.2)
> and Apache Commons DBCP2 features (since 2014, current version 2.1.1).
> Caveat: Commons Pool 2 requires Java 1.6, but DBCP 2 Java 1.7.
> Code changes seem to be minimal in only a few dsfactory classes. Maybe the
> easiest way to support version 2 pool/dbcp is to allow for another module
> runtime2 with appropriate dependencies?
> e.g. ...
>
> org.apache.torque
> torque-runtime
> ${project.version}
>
>
> commons-dbcp
> commons-dbcp
>
>
>
>
> org.apache.commons
> commons-dbcp2
> 2.1.1
>
--
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] [Assigned] (TORQUE-344) Update to Commons Pool/DBCP Version 2
[
https://issues.apache.org/jira/browse/TORQUE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl reassigned TORQUE-344:
-
Assignee: Thomas Vandahl
> Update to Commons Pool/DBCP Version 2
> -
>
> Key: TORQUE-344
> URL: https://issues.apache.org/jira/browse/TORQUE-344
> Project: Torque
> Issue Type: Improvement
> Components: Runtime
>Affects Versions: 4.1
>Reporter: Georg Kallidis
>Assignee: Thomas Vandahl
>
> Support for Apache Commons Pool Version 2 (since 2013, current verson 2.4.2)
> and Apache Commons DBCP2 features (since 2014, current version 2.1.1).
> Caveat: Commons Pool 2 requires Java 1.6, but DBCP 2 Java 1.7.
> Code changes seem to be minimal in only a few dsfactory classes. Maybe the
> easiest way to support version 2 pool/dbcp is to allow for another module
> runtime2 with appropriate dependencies?
> e.g. ...
>
> org.apache.torque
> torque-runtime
> ${project.version}
>
>
> commons-dbcp
> commons-dbcp
>
>
>
>
> org.apache.commons
> commons-dbcp2
> 2.1.1
>
--
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=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
[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] [Created] (TORQUE-343) Implement a central registry for peerImpls like the registry for managers
Thomas Vandahl created TORQUE-343:
-
Summary: 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] [Resolved] (TORQUE-342) XXXPeer.addSelectColumns() is declared to throw TorqueException for no apparent reason
[
https://issues.apache.org/jira/browse/TORQUE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved TORQUE-342.
---
Resolution: Fixed
Assignee: Thomas Vandahl
Fixed in SVN
> XXXPeer.addSelectColumns() is declared to throw TorqueException for no
> apparent reason
> --
>
> Key: TORQUE-342
> URL: https://issues.apache.org/jira/browse/TORQUE-342
> Project: Torque
> Issue Type: Improvement
> Components: Templates
>Affects Versions: 4.0
>Reporter: Thomas Vandahl
>Assignee: Thomas Vandahl
>Priority: Minor
> Fix For: 4.1
>
>
> For example {{AuthorPeer.addSelectColumns()}} is declared as
> {code:java}
> public static void addSelectColumns(Criteria criteria)
> throws TorqueException
> {
> getAuthorPeerImpl().addSelectColumns(criteria);
> }
> {code}
> {{getAuthorPeerImpl().addSelectColumns(criteria)}}, however actually calls
> {{BasePeerImpl.addSelectColumns(criteria)}} which does not throw any
> exceptions. Is this a leftover from previous times when the columns were
> drawn from the MapBuilders?
--
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] [Created] (TORQUE-342) XXXPeer.addSelectColumns() is declared to throw TorqueException for no apparent reason
Thomas Vandahl created TORQUE-342:
-
Summary: XXXPeer.addSelectColumns() is declared to throw
TorqueException for no apparent reason
Key: TORQUE-342
URL: https://issues.apache.org/jira/browse/TORQUE-342
Project: Torque
Issue Type: Improvement
Components: Templates
Affects Versions: 4.0
Reporter: Thomas Vandahl
Priority: Minor
Fix For: 4.1
For example {{AuthorPeer.addSelectColumns()}} is declared as
{code:java}
public static void addSelectColumns(Criteria criteria)
throws TorqueException
{
getAuthorPeerImpl().addSelectColumns(criteria);
}
{code}
{{getAuthorPeerImpl().addSelectColumns(criteria)}}, however actually calls
{{BasePeerImpl.addSelectColumns(criteria)}} which does not throw any
exceptions. Is this a leftover from previous times when the columns were drawn
from the MapBuilders?
--
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-304) getPeerByName generated incorrectly
[
https://issues.apache.org/jira/browse/TORQUE-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15125487#comment-15125487
]
Thomas Vandahl commented on TORQUE-304:
---
I'm not sure about the general use case here but in my applications I almost
exclusively use getByPeerName() with the Column constants generated in the Peer
objects. So I suggest to deprecate the above-mentioned methods and replace them
with something like setByColumn(Column, Object) and getByColumn(Column)
WDYT?
> getPeerByName generated incorrectly
> ---
>
> Key: TORQUE-304
> URL: https://issues.apache.org/jira/browse/TORQUE-304
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
>Reporter: Jeff Randolph
>Assignee: Thomas Fox
>Priority: Minor
> Fix For: 4.1
>
>
> The getByPeerName method is generated in the base db objects as follows:
> public Object getByPeerName(String name)
> {
> if (name.equals(org.abc.MyPeer.MyColumn))
> {
> return getMyColumn();
> }
> }
> This will never work because org.abc.MyPeer.MyColumn is a Column, not a
> String. It should instead generate this:
> public Object getByPeerName(String name)
> {
> if (name.equals(org.abc.MyPeer.MyColumn.getColumnName()))
> {
> return getMyColumn();
> }
> }
--
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-152) Torque issue with Record.getValue() using jtds jdbc driver for sqlserver
[
https://issues.apache.org/jira/browse/TORQUE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15103751#comment-15103751
]
Thomas Vandahl commented on TORQUE-152:
---
Village is not used anymore in Torque 4.0.
> Torque issue with Record.getValue() using jtds jdbc driver for sqlserver
>
>
> Key: TORQUE-152
> URL: https://issues.apache.org/jira/browse/TORQUE-152
> Project: Torque
> Issue Type: Bug
> Components: Runtime, Village
>Affects Versions: 3.3
> Environment: windows xp
>Reporter: Sethuraman Ramasubramanian
>Assignee: Thomas Vandahl
> Fix For: 3.3.1
>
> Original Estimate: 120h
> Remaining Estimate: 120h
>
> This is my code that cause a problem:
> Criteria crit=new Criteria();
> crit.addSelectColumn(FilingDtlsPeer.FILING_NO);
> crit.addJoin(FilingDtlsPeer.FILING_NO,CmpnyFilingPeer.FILING_NO);
> crit.addJoin(CmpnyFilingPeer.COMPANY_ID,CompanyPeer.COMPANY_ID);
> crit.add(CmpnyFilingPeer.COMPANY_ID,5);
> List toBeFiledDtls=BasePeer.doSelect(crit);
> for(Record r : toBeFiledDtls){
> System.out.println(r);
> System.out.println(r.getValue(FilingDtlsPeer.FILING_NO));
> }
> At this line "System.out.println(r.getValue(FilingDtlsPeer.FILING_NO));" I
> get an error - Column name: filing_no does not exist!
> The reason behind this is resultmetadata .getTableName() returns back an
> empty string from jtds.
> This is used in QueryDataSet(Connection conn, String
> selectStmt)->schema.populate(resultSet.getMetaData(),
> null)->col.populate(meta, i, tableName);->this.tableName =
> rsmd.getTableName(columnNumber)
> Since this tablename is null, in Record.getValue(String
> columnName)->index(columnName)->index(table,colname) - Over here it fails to
> find the table name and fails.
--
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-36) Select performance problem with Sybase
[ https://issues.apache.org/jira/browse/TORQUE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15103750#comment-15103750 ] Thomas Vandahl commented on TORQUE-36: -- Please note that Village is no longer used by Torque 4.0 > Select performance problem with Sybase > -- > > Key: TORQUE-36 > URL: https://issues.apache.org/jira/browse/TORQUE-36 > Project: Torque > Issue Type: Bug > Components: Runtime, Village >Affects Versions: 3.2 > Environment: Java 1.4.2 on solaris 10 against Sybase 12.5.2 >Reporter: Joe Carter >Assignee: Thomas Vandahl > Fix For: 3.3.1 > > > Selects via Torque perform 2-3 times slower than when doing the identical > statement via JDBC. > I took the SQL produced by Torque using p6spy to capture it. > I manually implemented the same SQL as a raw query and a prepared statement > obtaining a SQL connection from Torque.getConnection() to eliminate any > differences in the pooling etc. > I then ran performance tests against the 3 types. > The ratio in performance (big is slower) was 10-4-3 for standard Torque, raw > and then prepared statements. > The performance hit was definately against the database as we're seeing > similar performance improvements > on production systems with the database CPU usage dropping dramatically with > some gains on the calling tomcat server. > The suspicion is that metadata is being retrieved on every select but p6spy > unfortunately does not > support the reporting of this so this cannot be confirmed. > Note that the tests were performed without p6spy in the loop. -- 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-36) Select performance problem with Sybase
[ https://issues.apache.org/jira/browse/TORQUE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15103749#comment-15103749 ] Thomas Vandahl commented on TORQUE-36: -- Yes it was. Yes the problem may also apply to other databases. Many JDBC drivers cache metadata internally, however. > Select performance problem with Sybase > -- > > Key: TORQUE-36 > URL: https://issues.apache.org/jira/browse/TORQUE-36 > Project: Torque > Issue Type: Bug > Components: Runtime, Village >Affects Versions: 3.2 > Environment: Java 1.4.2 on solaris 10 against Sybase 12.5.2 >Reporter: Joe Carter >Assignee: Thomas Vandahl > Fix For: 3.3.1 > > > Selects via Torque perform 2-3 times slower than when doing the identical > statement via JDBC. > I took the SQL produced by Torque using p6spy to capture it. > I manually implemented the same SQL as a raw query and a prepared statement > obtaining a SQL connection from Torque.getConnection() to eliminate any > differences in the pooling etc. > I then ran performance tests against the 3 types. > The ratio in performance (big is slower) was 10-4-3 for standard Torque, raw > and then prepared statements. > The performance hit was definately against the database as we're seeing > similar performance improvements > on production systems with the database CPU usage dropping dramatically with > some gains on the calling tomcat server. > The suspicion is that metadata is being retrieved on every select but p6spy > unfortunately does not > support the reporting of this so this cannot be confirmed. > Note that the tests were performed without p6spy in the loop. -- 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] [Assigned] (TORQUE-335) Syntax error in DOAP file release section
[ https://issues.apache.org/jira/browse/TORQUE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl reassigned TORQUE-335: - Assignee: Thomas Vandahl Syntax error in DOAP file release section - Key: TORQUE-335 URL: https://issues.apache.org/jira/browse/TORQUE-335 Project: Torque Issue Type: Bug Environment: http://svn.apache.org/repos/asf/db/torque/trunks/doap_Torque.rdf Reporter: Sebb Assignee: Thomas Vandahl DOAP files can contain details of multiple release Versions, however each must be listed in a separate release section, for example: release Version nameApache XYZ/name created2015-02-16/created revision1.6.2/revision /Version /release release Version nameApache XYZ/name created2014-09-24/created revision1.6.1/revision /Version /release Please can the project DOAP be corrected accordingly? Thanks. -- 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] [Resolved] (TORQUE-335) Syntax error in DOAP file release section
[ https://issues.apache.org/jira/browse/TORQUE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-335. --- Resolution: Fixed Fixed in SVN Syntax error in DOAP file release section - Key: TORQUE-335 URL: https://issues.apache.org/jira/browse/TORQUE-335 Project: Torque Issue Type: Bug Environment: http://svn.apache.org/repos/asf/db/torque/trunks/doap_Torque.rdf Reporter: Sebb Assignee: Thomas Vandahl DOAP files can contain details of multiple release Versions, however each must be listed in a separate release section, for example: release Version nameApache XYZ/name created2015-02-16/created revision1.6.2/revision /Version /release release Version nameApache XYZ/name created2014-09-24/created revision1.6.1/revision /Version /release Please can the project DOAP be corrected accordingly? Thanks. -- 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-320) GroupBy adds columns to the select clause
[ https://issues.apache.org/jira/browse/TORQUE-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100054#comment-14100054 ] Thomas Vandahl commented on TORQUE-320: --- My point just was that I remember especially Oracle barking on me because the column used in the GROUP BY clause was not listed in the selected columns. I don't know when this happens, it might be a totally unrelated case. You have much more Oracle experience than I. In my case the different methods would not have helped much because it's the database that throws the error. I just wanted to make sure that Torque does not create invalid SQL for some DBs. I'm unhappy with the ILIKE operator already. GroupBy adds columns to the select clause - Key: TORQUE-320 URL: https://issues.apache.org/jira/browse/TORQUE-320 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 4.0 Reporter: Thomas Fox If I create a Criteria, define the select columns manually and then add groupBy Columns, SqlBuilder adds the groupBy Columns to the select columns One should be able to create GROUP BY Queries without adding the columns to the select clause -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-320) GroupBy adds columns to the select clause
[ https://issues.apache.org/jira/browse/TORQUE-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065416#comment-14065416 ] Thomas Vandahl commented on TORQUE-320: --- There are database systems that require group-by columns to be part of the select clause. So this change should be DBMS-dependent. GroupBy adds columns to the select clause - Key: TORQUE-320 URL: https://issues.apache.org/jira/browse/TORQUE-320 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 4.0 Reporter: Thomas Fox If I create a Criteria, define the select columns manually and then add groupBy Columns, SqlBuilder adds the groupBy Columns to the select columns One should be able to create GROUP BY Queries without adding the columns to the select clause -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-292) The feature of runOnlyOnSchemaChange is missing from the maven plugin
Thomas Vandahl created TORQUE-292: - Summary: The feature of runOnlyOnSchemaChange is missing from the maven plugin Key: TORQUE-292 URL: https://issues.apache.org/jira/browse/TORQUE-292 Project: Torque Issue Type: Improvement Components: Maven 2 Plugin Affects Versions: 4.0 Reporter: Thomas Vandahl The Mavan plugin used to have a feature to skip the generation of source files if the schema file is unchanged. This feature is missing from the version 4.0 of the plugin and should be re-implemented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-293) The generated OM classes of object A contain a method getAtoBJoinA() where they should contain a method getAtoBJoinB()
Thomas Vandahl created TORQUE-293: - Summary: The generated OM classes of object A contain a method getAtoBJoinA() where they should contain a method getAtoBJoinB() Key: TORQUE-293 URL: https://issues.apache.org/jira/browse/TORQUE-293 Project: Torque Issue Type: Bug Components: Templates Affects Versions: 4.0 Reporter: Thomas Vandahl I use the getAJoinB() methods in the OM classes. I have the following table relation: A - AtoB - B Now in A there used to be a generated method getAtoBJoinB(Criteria) whereas in Torque4 there is only getAtoBJoinA(Criteria). This feature was very helpful when dealing with m:n relations. It allowed to access all Bs that belong to a certain A with one call. So to get all As that belong to a certain A is not very useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-294) An example for the generation of the Init-ID-Table-SQL is missing from the docs.
Thomas Vandahl created TORQUE-294: - Summary: An example for the generation of the Init-ID-Table-SQL is missing from the docs. Key: TORQUE-294 URL: https://issues.apache.org/jira/browse/TORQUE-294 Project: Torque Issue Type: Bug Components: Documentation, Maven 2 Plugin Affects Versions: 4.0 Reporter: Thomas Vandahl Priority: Minor The only place one can find such an example is the POM of the Torque test project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-250) Fix documentation issues
[
https://issues.apache.org/jira/browse/TORQUE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13561586#comment-13561586
]
Thomas Vandahl commented on TORQUE-250:
---
I was able to fix the compiler failure by adding a simple cast to (T). No idea
why this works. Note that the same construct in a non-static method compiles
fine.
Anyhow, the Torque Runtime compiles fine now with jdk 1.5.0_22 under Windows.
Fix documentation issues
Key: TORQUE-250
URL: https://issues.apache.org/jira/browse/TORQUE-250
Project: Torque
Issue Type: Bug
Components: Documentation
Reporter: Greg Monroe
Assignee: Thomas Fox
Fix For: 4.0
- Need strong notice about problems building with older JDK. Probably in the
SVN/Build page
- Test Project page refers to profiles.xml which does not exist but is part
of the Pom.xml
- Test Project page should mention editing the Torque.properties in the
src/test/profile/${profile} directory
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-250) Fix documentation issues
[
https://issues.apache.org/jira/browse/TORQUE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13550954#comment-13550954
]
Thomas Vandahl commented on TORQUE-250:
---
I'd suggest to add the restriction to the build file like described in
http://blogs.bytecode.com.au/glen/2009/09/15/maven-tip-enforcing-a-jdk-version-in-your-build.html
Fix documentation issues
Key: TORQUE-250
URL: https://issues.apache.org/jira/browse/TORQUE-250
Project: Torque
Issue Type: Bug
Components: Documentation
Reporter: Greg Monroe
Assignee: Thomas Fox
Fix For: 4.0
- Need strong notice about problems building with older JDK. Probably in the
SVN/Build page
- Test Project page refers to profiles.xml which does not exist but is part
of the Pom.xml
- Test Project page should mention editing the Torque.properties in the
src/test/profile/${profile} directory
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-250) Fix documentation issues
[
https://issues.apache.org/jira/browse/TORQUE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13550966#comment-13550966
]
Thomas Vandahl commented on TORQUE-250:
---
I'll try to fix the original issue by re-writing the piece of code in question.
Then we can lift the restriction again. WDYT?
Fix documentation issues
Key: TORQUE-250
URL: https://issues.apache.org/jira/browse/TORQUE-250
Project: Torque
Issue Type: Bug
Components: Documentation
Reporter: Greg Monroe
Assignee: Thomas Fox
Fix For: 4.0
- Need strong notice about problems building with older JDK. Probably in the
SVN/Build page
- Test Project page refers to profiles.xml which does not exist but is part
of the Pom.xml
- Test Project page should mention editing the Torque.properties in the
src/test/profile/${profile} directory
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-203) Quote table names in creation
[ https://issues.apache.org/jira/browse/TORQUE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13291589#comment-13291589 ] Thomas Vandahl commented on TORQUE-203: --- As a starting point, this is of course acceptable. Nevertheless, there are reserved words specific to a certain DBMS. See http://www.csee.umbc.edu/portal/help/oracle8/server.815/a42525/apb.htm for the Oracle-flavor. Example: COMMENT is a reserved word in Oracle but not in the Postgres table. Let's try to collect the lists for the supported DBMSs and look for a reasonable set. Quote table names in creation - Key: TORQUE-203 URL: https://issues.apache.org/jira/browse/TORQUE-203 Project: Torque Issue Type: Improvement Reporter: Thomas Fox For some databases, table names can be quoted in the sql create scripts to avoid collisions with predefined names. Where possible, such quotation should be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=13060351#comment-13060351 ] Thomas Vandahl commented on TORQUE-163: --- Actually, the code in TorqueInstance.java (line 164ff) was supposed to handle (or rather work around) a similar case. Obviously, the removal of the cache entry in line 691 breaks this intention. Torque has no means of knowing which peers actually exist right now. Do we want to change that? It would probably have lots of implications. Bye, Thomas. 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] [Updated] (TORQUE-152) Torque issue with Record.getValue() using jtds jdbc driver for sqlserver
[
https://issues.apache.org/jira/browse/TORQUE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl updated TORQUE-152:
--
Fix Version/s: (was: 3.3)
3.3.1
Torque issue with Record.getValue() using jtds jdbc driver for sqlserver
Key: TORQUE-152
URL: https://issues.apache.org/jira/browse/TORQUE-152
Project: Torque
Issue Type: Bug
Components: Runtime, Village
Affects Versions: 3.3
Environment: windows xp
Reporter: Sethuraman Ramasubramanian
Assignee: Thomas Vandahl
Fix For: 3.3.1
Original Estimate: 120h
Remaining Estimate: 120h
This is my code that cause a problem:
Criteria crit=new Criteria();
crit.addSelectColumn(FilingDtlsPeer.FILING_NO);
crit.addJoin(FilingDtlsPeer.FILING_NO,CmpnyFilingPeer.FILING_NO);
crit.addJoin(CmpnyFilingPeer.COMPANY_ID,CompanyPeer.COMPANY_ID);
crit.add(CmpnyFilingPeer.COMPANY_ID,5);
ListRecord toBeFiledDtls=BasePeer.doSelect(crit);
for(Record r : toBeFiledDtls){
System.out.println(r);
System.out.println(r.getValue(FilingDtlsPeer.FILING_NO));
}
At this line System.out.println(r.getValue(FilingDtlsPeer.FILING_NO)); I
get an error - Column name: filing_no does not exist!
The reason behind this is resultmetadata .getTableName() returns back an
empty string from jtds.
This is used in QueryDataSet(Connection conn, String
selectStmt)-schema.populate(resultSet.getMetaData(),
null)-col.populate(meta, i, tableName);-this.tableName =
rsmd.getTableName(columnNumber)
Since this tablename is null, in Record.getValue(String
columnName)-index(columnName)-index(table,colname) - Over here it fails to
find the table name and fails.
--
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-152) Torque issue with Record.getValue() using jtds jdbc driver for sqlserver
[
https://issues.apache.org/jira/browse/TORQUE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved TORQUE-152.
---
Resolution: Incomplete
As I see no response, I mark this as resolved
Torque issue with Record.getValue() using jtds jdbc driver for sqlserver
Key: TORQUE-152
URL: https://issues.apache.org/jira/browse/TORQUE-152
Project: Torque
Issue Type: Bug
Components: Runtime, Village
Affects Versions: 3.3
Environment: windows xp
Reporter: Sethuraman Ramasubramanian
Assignee: Thomas Vandahl
Fix For: 3.3.1
Original Estimate: 120h
Remaining Estimate: 120h
This is my code that cause a problem:
Criteria crit=new Criteria();
crit.addSelectColumn(FilingDtlsPeer.FILING_NO);
crit.addJoin(FilingDtlsPeer.FILING_NO,CmpnyFilingPeer.FILING_NO);
crit.addJoin(CmpnyFilingPeer.COMPANY_ID,CompanyPeer.COMPANY_ID);
crit.add(CmpnyFilingPeer.COMPANY_ID,5);
ListRecord toBeFiledDtls=BasePeer.doSelect(crit);
for(Record r : toBeFiledDtls){
System.out.println(r);
System.out.println(r.getValue(FilingDtlsPeer.FILING_NO));
}
At this line System.out.println(r.getValue(FilingDtlsPeer.FILING_NO)); I
get an error - Column name: filing_no does not exist!
The reason behind this is resultmetadata .getTableName() returns back an
empty string from jtds.
This is used in QueryDataSet(Connection conn, String
selectStmt)-schema.populate(resultSet.getMetaData(),
null)-col.populate(meta, i, tableName);-this.tableName =
rsmd.getTableName(columnNumber)
Since this tablename is null, in Record.getValue(String
columnName)-index(columnName)-index(table,colname) - Over here it fails to
find the table name and fails.
--
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] Closed: (TORQUE-154) A BLOB with NULL as its value causes a Null Pointer Exception
[
https://issues.apache.org/jira/browse/TORQUE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl closed TORQUE-154.
-
The patch is contained in village-3.3.1
A BLOB with NULL as its value causes a Null Pointer Exception
-
Key: TORQUE-154
URL: https://issues.apache.org/jira/browse/TORQUE-154
Project: Torque
Issue Type: Bug
Components: Village
Affects Versions: 3.3
Environment: windows, mssql 2005
Reporter: Rich Diaz
Priority: Critical
Fix For: 3.3
Attachments: npe-null-blob.patch
NPE was thrown while running the datadump task on MSSQL database. It first
happened on Torque-gen 3.1 which has village-2.0.jar, so I took the
village-3.3.jar from torque-gen-3.3.
I did a search and found this link
http://mail-archives.apache.org/mod_mbox/turbine-user/200401.mbox/%3c373ec11e4993df4f9dcbd2e630568ce31f8...@xch-au-20.au.nos.boeing.com%3E
Looks like someone found that out in 2004.
For village 3.3 the NPE is in Value.java line 153. I checked out the village
source from svn, put a null check and I was able to get my datadump working.
It's a simple null check fix. I don't see where to attach a file to this
ticket so i'll just post the code here.
if(blob!=null){
valueObject = blob.getBytes(1, (int) blob.length());
}
--
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] Closed: (TORQUE-8) village does not close every resultSet it opens
[ https://issues.apache.org/jira/browse/TORQUE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed TORQUE-8. --- Fixed in village-3.3.1 village does not close every resultSet it opens Key: TORQUE-8 URL: https://issues.apache.org/jira/browse/TORQUE-8 Project: Torque Issue Type: Bug Components: Runtime, Village Affects Versions: 3.0, 3.1, 3.1.1, 3.2 Reporter: Thomas Fox Assignee: Thomas Vandahl Fix For: 3.3.1 Attachments: village-2.0-TORQUE-8.patch, village-3.3-TORQUE-8.patch In the village classes Record and Schema, ResultSets are opened which are not closed afterwards. This can lead to a too many open cursors error in oracle. Thanks to Hendrik Busch for reporting the error. -- 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] Updated: (TORQUE-149) If silentDbFetch is false, the add method for a related object has a throws clause
[
https://issues.apache.org/jira/browse/TORQUE-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl updated TORQUE-149:
--
Fix Version/s: (was: 3.3.1)
4.0
Move fix to version 4.0
If silentDbFetch is false, the add method for a related object has a throws
clause
--
Key: TORQUE-149
URL: https://issues.apache.org/jira/browse/TORQUE-149
Project: Torque
Issue Type: Bug
Reporter: Thomas Fox
Assignee: Thomas Fox
Fix For: 4.0
If the option torque.om.silentDbFetch is false (which is NOT the default
value), then Torque generates from the schema
table name=book description=Book table
foreign-key foreignTable=author
reference local=author_id foreign=author_id/
/foreign-key
/table
the following code in BaseAuthor:
public void addBook(Book l) throws TorqueException
{
getBooks().add(l);
l.setAuthor((Author) this);
}
The throws clause is unnecessary because no Torque exception is created in
the associated code. Thus the throws clause should be removed.
--
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] Closed: (TORQUE-123) Statement is left open when Exception is thrown in the QueryDataSet constructor (ORA-01000)
[
https://issues.apache.org/jira/browse/TORQUE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl closed TORQUE-123.
-
Fixed in village-3.3.1
Statement is left open when Exception is thrown in the QueryDataSet
constructor (ORA-01000)
-
Key: TORQUE-123
URL: https://issues.apache.org/jira/browse/TORQUE-123
Project: Torque
Issue Type: Bug
Components: Village
Affects Versions: 3.3
Environment: OS ：RedHat Enterprise Linux ES 4 update 4
Java ：1.4.2_08
Tomcat：4.1.31
Torque：3.0.2
JDBC(Oracle): ojdbc.jar(10.2.0.4)
Reporter: Kazu Nambo
Assignee: Thomas Fox
Fix For: 3.3.1
When syntax error(SQLException) happens at executeQuery in the constructor
QueryDataSet(Connection conn, String selectStmt), the member stmt is left
open and this problem sometimes results in ORA-01000 (Maximum open cursors
exceeded).
In the upper layer like BasePeer#executeQuery method, it tries to close
QueryDataSet instance by VillageUtils.close but it fails because the instance
is null.
Other exceptions may result in the same situation.
If I try to make the constructor more robust as follows, it will work. (No
ORA-01000)
public QueryDataSet(Connection conn, String selectStmt)
throws SQLException, DataSetException
{
this.conn = conn;
selectString = new StringBuffer(selectStmt);
try
{
stmt = conn.createStatement();
resultSet = stmt.executeQuery(selectStmt);
schema = new Schema();
schema.populate(resultSet.getMetaData(), null);
}
catch (Exception e)
{
try {
if (null != resultSet) {
resultSet.close();
}
} catch (Exception ignored) {}
try {
if (null != stmt) {
stmt.close();
}
} catch (Exception ignored) {}
if (e instanceof SQLException)
throw (SQLException)e;
else if (e instanceof DataSetException)
throw (DataSetException)e;
else
throw new SQLException(QueryDataSet: exception
caught., e);
}
}
--
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-36) Select performance problem with Sybase
[ https://issues.apache.org/jira/browse/TORQUE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl reassigned TORQUE-36: Assignee: Thomas Vandahl Select performance problem with Sybase -- Key: TORQUE-36 URL: https://issues.apache.org/jira/browse/TORQUE-36 Project: Torque Issue Type: Bug Components: Runtime, Village Affects Versions: 3.2 Environment: Java 1.4.2 on solaris 10 against Sybase 12.5.2 Reporter: Joe Carter Assignee: Thomas Vandahl Selects via Torque perform 2-3 times slower than when doing the identical statement via JDBC. I took the SQL produced by Torque using p6spy to capture it. I manually implemented the same SQL as a raw query and a prepared statement obtaining a SQL connection from Torque.getConnection() to eliminate any differences in the pooling etc. I then ran performance tests against the 3 types. The ratio in performance (big is slower) was 10-4-3 for standard Torque, raw and then prepared statements. The performance hit was definately against the database as we're seeing similar performance improvements on production systems with the database CPU usage dropping dramatically with some gains on the calling tomcat server. The suspicion is that metadata is being retrieved on every select but p6spy unfortunately does not support the reporting of this so this cannot be confirmed. Note that the tests were performed without p6spy in the loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] Resolved: (TORQUE-36) Select performance problem with Sybase
[ https://issues.apache.org/jira/browse/TORQUE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-36. -- Resolution: Fixed Fix Version/s: 3.3.1 Well, not exactly fixed, actually. More worked around. You can preload the table metadata beforehand to cache it. The select will then use the cached information to improve performance. Select performance problem with Sybase -- Key: TORQUE-36 URL: https://issues.apache.org/jira/browse/TORQUE-36 Project: Torque Issue Type: Bug Components: Runtime, Village Affects Versions: 3.2 Environment: Java 1.4.2 on solaris 10 against Sybase 12.5.2 Reporter: Joe Carter Assignee: Thomas Vandahl Fix For: 3.3.1 Selects via Torque perform 2-3 times slower than when doing the identical statement via JDBC. I took the SQL produced by Torque using p6spy to capture it. I manually implemented the same SQL as a raw query and a prepared statement obtaining a SQL connection from Torque.getConnection() to eliminate any differences in the pooling etc. I then ran performance tests against the 3 types. The ratio in performance (big is slower) was 10-4-3 for standard Torque, raw and then prepared statements. The performance hit was definately against the database as we're seeing similar performance improvements on production systems with the database CPU usage dropping dramatically with some gains on the calling tomcat server. The suspicion is that metadata is being retrieved on every select but p6spy unfortunately does not support the reporting of this so this cannot be confirmed. Note that the tests were performed without p6spy in the loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] Commented: (TORQUE-128) remove autoIncrement attribute of column element
[ https://issues.apache.org/jira/browse/TORQUE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908152#action_12908152 ] Thomas Vandahl commented on TORQUE-128: --- Well, I have no problem with the name. It actually exactly describes what it does for the column: automatically increment its value Just because others call this different we should not use foggy terms for simple things :-) I would leave it in as-is. remove autoIncrement attribute of column element Key: TORQUE-128 URL: https://issues.apache.org/jira/browse/TORQUE-128 Project: Torque Issue Type: Sub-task Affects Versions: 4.0 Reporter: Thomas Fischer Fix For: 4.0 In the 3.3 schema, the id method for a column is determined by the idMethod attribute of the table, the defaultIdMethod attribute of the database and the primaryKey attribute of the column. This is sufficient for determining the idMethod. However, in the 3.3 schema, there is still the autoIncrement attribute which kind of overrides the settings outlined above. There is no such equivalent for sequence generation, thus the attribute is bad for database interoperability. Therefore I'd suggest to remove this attribute with no replacement. The consequence would be that it would no longer be possible to have auto_increment on columns which are no primary key (but again, torque supports no such feature for sequence generation). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] Updated: (TORQUE-113) doDelete with invalid column should throw exception, not delete all rows
[
https://issues.apache.org/jira/browse/TORQUE-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl updated TORQUE-113:
--
Fix Version/s: (was: 3.3)
doDelete with invalid column should throw exception, not delete all rows
Key: TORQUE-113
URL: https://issues.apache.org/jira/browse/TORQUE-113
Project: Torque
Issue Type: Bug
Components: Runtime
Affects Versions: 3.3
Reporter: Julian Zinn
Fix For: 4.0
The following (incorrect) client code should cause an exception to be thrown.
Instead of an exception, all rows in table T1 are deleted.
{code}
T1Peer.doDelete(new Criteria().add(T2Peer.COL, 2));
{code}
This code appeared in a project I am working on. The intent was to delete
rows from table T2.
Before the fix for TORQUE-93, this code had the intended effect becaue
{{T1Peer.doDelete(criteria)}} just passed the criteria object to
{{BasePeer.doDelete(criteria)}}. Since the only reference BasePeer had to a
table was table T2 in the criteria, only rows in table T2 were deleted.
Now that {{T1Peer.doDelete(criteria)}} calls {{BasePeer.doDelete(criteria,
TABLE_NAME)}} instead, the test {{if (crit.containsKey(key))}} in
{{BasePeer.processTables()}} always fails. This leads to an empty where
clause, causing all rows in table T1 to be deleted.
*Expect*: All Criterion objects in a Criteria should be used in the final
where clause. If not, an exception should be thrown.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] Updated: (TORQUE-84) Limit/Offset solution for MSSQL Server
[ https://issues.apache.org/jira/browse/TORQUE-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated TORQUE-84: - Fix Version/s: 4.0 (was: 3.3) Limit/Offset solution for MSSQL Server -- Key: TORQUE-84 URL: https://issues.apache.org/jira/browse/TORQUE-84 Project: Torque Issue Type: Improvement Components: Runtime Affects Versions: 3.3 Environment: MSSQL Server Reporter: Tobias Hilka Fix For: 4.0 Attachments: DBMSSQL.java, DBOracle.java Solved the limit/offset problem for MSSQL. Maybe needs some fine tuning according to torque rules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] Commented: (TORQUE-123) Statement is left open when Exception is thrown in the QueryDataSet constructor (ORA-01000)
[
https://issues.apache.org/jira/browse/TORQUE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897219#action_12897219
]
Thomas Vandahl commented on TORQUE-123:
---
Thank you, that looks better. Care to commit it? Go ahead.
Statement is left open when Exception is thrown in the QueryDataSet
constructor (ORA-01000)
-
Key: TORQUE-123
URL: https://issues.apache.org/jira/browse/TORQUE-123
Project: Torque
Issue Type: Bug
Components: Village
Affects Versions: 3.3
Environment: OS ：RedHat Enterprise Linux ES 4 update 4
Java ：1.4.2_08
Tomcat：4.1.31
Torque：3.0.2
JDBC(Oracle): ojdbc.jar(10.2.0.4)
Reporter: Kazu Nambo
Assignee: Thomas Fischer
Fix For: 3.3.1
When syntax error(SQLException) happens at executeQuery in the constructor
QueryDataSet(Connection conn, String selectStmt), the member stmt is left
open and this problem sometimes results in ORA-01000 (Maximum open cursors
exceeded).
In the upper layer like BasePeer#executeQuery method, it tries to close
QueryDataSet instance by VillageUtils.close but it fails because the instance
is null.
Other exceptions may result in the same situation.
If I try to make the constructor more robust as follows, it will work. (No
ORA-01000)
public QueryDataSet(Connection conn, String selectStmt)
throws SQLException, DataSetException
{
this.conn = conn;
selectString = new StringBuffer(selectStmt);
try
{
stmt = conn.createStatement();
resultSet = stmt.executeQuery(selectStmt);
schema = new Schema();
schema.populate(resultSet.getMetaData(), null);
}
catch (Exception e)
{
try {
if (null != resultSet) {
resultSet.close();
}
} catch (Exception ignored) {}
try {
if (null != stmt) {
stmt.close();
}
} catch (Exception ignored) {}
if (e instanceof SQLException)
throw (SQLException)e;
else if (e instanceof DataSetException)
throw (DataSetException)e;
else
throw new SQLException(QueryDataSet: exception
caught., e);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] Assigned: (TORQUE-8) village does not close every resultSet it opens
[ https://issues.apache.org/jira/browse/TORQUE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl reassigned TORQUE-8: --- Assignee: Thomas Vandahl village does not close every resultSet it opens Key: TORQUE-8 URL: https://issues.apache.org/jira/browse/TORQUE-8 Project: Torque Issue Type: Bug Components: Runtime, Village Affects Versions: 3.0, 3.1, 3.1.1, 3.2 Reporter: Thomas Fischer Assignee: Thomas Vandahl Attachments: village-2.0-TORQUE-8.patch, village-3.3-TORQUE-8.patch In the village classes Record and Schema, ResultSets are opened which are not closed afterwards. This can lead to a too many open cursors error in oracle. Thanks to Hendrik Busch for reporting the error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] Resolved: (TORQUE-8) village does not close every resultSet it opens
[ https://issues.apache.org/jira/browse/TORQUE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-8. - Fix Version/s: 3.3.1 Resolution: Fixed Applied patch and some cleanup village does not close every resultSet it opens Key: TORQUE-8 URL: https://issues.apache.org/jira/browse/TORQUE-8 Project: Torque Issue Type: Bug Components: Runtime, Village Affects Versions: 3.0, 3.1, 3.1.1, 3.2 Reporter: Thomas Fischer Assignee: Thomas Vandahl Fix For: 3.3.1 Attachments: village-2.0-TORQUE-8.patch, village-3.3-TORQUE-8.patch In the village classes Record and Schema, ResultSets are opened which are not closed afterwards. This can lead to a too many open cursors error in oracle. Thanks to Hendrik Busch for reporting the error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] Assigned: (TORQUE-123) Statement is left open when Exception is thrown in the QueryDataSet constructor (ORA-01000)
[
https://issues.apache.org/jira/browse/TORQUE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl reassigned TORQUE-123:
-
Assignee: Thomas Vandahl
Statement is left open when Exception is thrown in the QueryDataSet
constructor (ORA-01000)
-
Key: TORQUE-123
URL: https://issues.apache.org/jira/browse/TORQUE-123
Project: Torque
Issue Type: Bug
Components: Village
Affects Versions: 3.3
Environment: OS ：RedHat Enterprise Linux ES 4 update 4
Java ：1.4.2_08
Tomcat：4.1.31
Torque：3.0.2
JDBC(Oracle): ojdbc.jar(10.2.0.4)
Reporter: Kazu Nambo
Assignee: Thomas Vandahl
When syntax error(SQLException) happens at executeQuery in the constructor
QueryDataSet(Connection conn, String selectStmt), the member stmt is left
open and this problem sometimes results in ORA-01000 (Maximum open cursors
exceeded).
In the upper layer like BasePeer#executeQuery method, it tries to close
QueryDataSet instance by VillageUtils.close but it fails because the instance
is null.
Other exceptions may result in the same situation.
If I try to make the constructor more robust as follows, it will work. (No
ORA-01000)
public QueryDataSet(Connection conn, String selectStmt)
throws SQLException, DataSetException
{
this.conn = conn;
selectString = new StringBuffer(selectStmt);
try
{
stmt = conn.createStatement();
resultSet = stmt.executeQuery(selectStmt);
schema = new Schema();
schema.populate(resultSet.getMetaData(), null);
}
catch (Exception e)
{
try {
if (null != resultSet) {
resultSet.close();
}
} catch (Exception ignored) {}
try {
if (null != stmt) {
stmt.close();
}
} catch (Exception ignored) {}
if (e instanceof SQLException)
throw (SQLException)e;
else if (e instanceof DataSetException)
throw (DataSetException)e;
else
throw new SQLException(QueryDataSet: exception
caught., e);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] Resolved: (TORQUE-123) Statement is left open when Exception is thrown in the QueryDataSet constructor (ORA-01000)
[
https://issues.apache.org/jira/browse/TORQUE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved TORQUE-123.
---
Fix Version/s: 3.3.1
Resolution: Fixed
Applied slightly simplified patch
Statement is left open when Exception is thrown in the QueryDataSet
constructor (ORA-01000)
-
Key: TORQUE-123
URL: https://issues.apache.org/jira/browse/TORQUE-123
Project: Torque
Issue Type: Bug
Components: Village
Affects Versions: 3.3
Environment: OS ：RedHat Enterprise Linux ES 4 update 4
Java ：1.4.2_08
Tomcat：4.1.31
Torque：3.0.2
JDBC(Oracle): ojdbc.jar(10.2.0.4)
Reporter: Kazu Nambo
Assignee: Thomas Vandahl
Fix For: 3.3.1
When syntax error(SQLException) happens at executeQuery in the constructor
QueryDataSet(Connection conn, String selectStmt), the member stmt is left
open and this problem sometimes results in ORA-01000 (Maximum open cursors
exceeded).
In the upper layer like BasePeer#executeQuery method, it tries to close
QueryDataSet instance by VillageUtils.close but it fails because the instance
is null.
Other exceptions may result in the same situation.
If I try to make the constructor more robust as follows, it will work. (No
ORA-01000)
public QueryDataSet(Connection conn, String selectStmt)
throws SQLException, DataSetException
{
this.conn = conn;
selectString = new StringBuffer(selectStmt);
try
{
stmt = conn.createStatement();
resultSet = stmt.executeQuery(selectStmt);
schema = new Schema();
schema.populate(resultSet.getMetaData(), null);
}
catch (Exception e)
{
try {
if (null != resultSet) {
resultSet.close();
}
} catch (Exception ignored) {}
try {
if (null != stmt) {
stmt.close();
}
} catch (Exception ignored) {}
if (e instanceof SQLException)
throw (SQLException)e;
else if (e instanceof DataSetException)
throw (DataSetException)e;
else
throw new SQLException(QueryDataSet: exception
caught., e);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] Commented: (TORQUE-125) Maven2 Plugin fails on local M2 repo containing spaces
[ https://issues.apache.org/jira/browse/TORQUE-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12774678#action_12774678 ] Thomas Vandahl commented on TORQUE-125: --- I'd love to agree, just that no path is handled by our code... I'm sorry I don't know what we could do here. Maven2 Plugin fails on local M2 repo containing spaces -- Key: TORQUE-125 URL: https://issues.apache.org/jira/browse/TORQUE-125 Project: Torque Issue Type: Bug Components: Maven 2 Plugin Affects Versions: 3.3 Environment: Maven version: 2.0.9 Java version: 1.6.0_07 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Siegfried Goeschl When invoking the plugin I get the following error (see below) - it does not like the spaces in C:/Dokumente und Einstellungen/goeschl/. When moving the local repo to a properly named location everything works === START OF STDOUT === Downloading: http://repo1.maven.org/maven2/hsqldb/hsqldb/1.8.0.7/hsqldb-1.8.0.7.jar [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null Illegal character in path at index 18: file:/C:/Dokumente und Einstellungen/goeschl/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar [INFO] [INFO] Trace java.lang.IllegalArgumentException at java.net.URI.create(URI.java:842) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.launch.Locator.fromURI(Locator.java:162) at org.apache.tools.ant.launch.Locator.getResourceSource(Locator.java:119) at org.apache.tools.ant.launch.Locator.getClassSource(Locator.java:90) at org.apache.tools.ant.Project.setAntLib(Project.java:313) at org.apache.tools.ant.Project.initProperties(Project.java:309) at org.apache.tools.ant.Project.init(Project.java:295) at org.apache.torque.mojo.TexenTaskMojo.setGeneratorTask(TexenTaskMojo.java:126) at org.apache.torque.mojo.TexenTaskMojo.init(TexenTaskMojo.java:109) at org.apache.torque.mojo.DataModelTaskMojo.init(DataModelTaskMojo.java:111) at org.apache.torque.mojo.OMMojo.init(OMMojo.java:461) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44) at org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(DefaultPlexusContainer.java:1464) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:93) at org.codehaus.plexus.component.manager.PerLookupComponentManager.getComponent(PerLookupComponentManager.java:48) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:609) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:429) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
[jira] Resolved: (TORQUE-121) Peer generation, using Peer.vm does not call super class' methods but always calls BasePeer.method(...)
[
https://issues.apache.org/jira/browse/TORQUE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved TORQUE-121.
---
Resolution: Fixed
Fix Version/s: 4.0
Fixed in SVN
Peer generation, using Peer.vm does not call super class' methods but always
calls BasePeer.method(...)
---
Key: TORQUE-121
URL: https://issues.apache.org/jira/browse/TORQUE-121
Project: Torque
Issue Type: Bug
Affects Versions: 3.1.1
Environment: Java
Reporter: Tal Kramer
Assignee: Thomas Vandahl
Fix For: 4.0
Attachments: Peer.vm
When generating the om, the *Peer generated classes call BasePeer methods
when calling to the original method, This ignores the base class.
On generation, it is possible to define a basePeer object, but it is
irrelevant at the current state since it is not used within the static
generated class.
To fix it, I have replaced in torque-gen.XX.jar in the file om/Peer.vm all
calls to BasePeer.method(...) by ${table.BasePeer}.method(...). Is there a
better solution? Or anything wrong with this suggestion?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] Assigned: (TORQUE-121) Peer generation, using Peer.vm does not call super class' methods but always calls BasePeer.method(...)
[
https://issues.apache.org/jira/browse/TORQUE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl reassigned TORQUE-121:
-
Assignee: Thomas Vandahl
Peer generation, using Peer.vm does not call super class' methods but always
calls BasePeer.method(...)
---
Key: TORQUE-121
URL: https://issues.apache.org/jira/browse/TORQUE-121
Project: Torque
Issue Type: Bug
Affects Versions: 3.1.1
Environment: Java
Reporter: Tal Kramer
Assignee: Thomas Vandahl
Fix For: 4.0
Attachments: Peer.vm
When generating the om, the *Peer generated classes call BasePeer methods
when calling to the original method, This ignores the base class.
On generation, it is possible to define a basePeer object, but it is
irrelevant at the current state since it is not used within the static
generated class.
To fix it, I have replaced in torque-gen.XX.jar in the file om/Peer.vm all
calls to BasePeer.method(...) by ${table.BasePeer}.method(...). Is there a
better solution? Or anything wrong with this suggestion?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] Created: (TORQUE-114) BigDecimal values can cause an Exception Value TRUNCATED from MySQL
BigDecimal values can cause an Exception Value TRUNCATED from MySQL - Key: TORQUE-114 URL: https://issues.apache.org/jira/browse/TORQUE-114 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 3.3 Environment: MySQL 4.1 Reporter: Thomas Vandahl Assignee: Thomas Vandahl Priority: Minor This is merely a bookmark for an issue that needs to be discussed When saving BigDecimal values, the database can throw an SQLException which basically says Value too long, has been truncated in MySQL. The case happens when a BigDecimal object has been created from a double value and as such contains a large number of frational digits (46 in my case) and the database column is declared as DECIMAL(11,2) Is it or is it not the responsibility of Torque to handle this case? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TORQUE-109) Torque Runtime fails SqlExpressionTest with Java 1.6
[ https://issues.apache.org/jira/browse/TORQUE-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-109. --- Resolution: Fixed Fix Version/s: 3.3-RC3 Assignee: Scott Eade I take the liberty to mark this issue as resolved. Torque Runtime fails SqlExpressionTest with Java 1.6 Key: TORQUE-109 URL: https://issues.apache.org/jira/browse/TORQUE-109 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 3.3-RC1, 3.3-RC2, 3.3-RC3 Environment: Linux, Java 1.6 Reporter: Brendan Miller Assignee: Scott Eade Fix For: 3.3-RC3 Attachments: sqlexpressiontest.patch (posted on torque-devel) I had a question about 3.3-RC3. Am I the only one for whom the SqlExpressionTest fails? Surely this cannot be. I am building from a clean svn co of the TORQUE_3_3_RC3 tag(s). $ maven jar:jar .. [junit] Running org.apache.torque.util.SqlExpressionTest [junit] Tests run: 5, Failures: 1, Errors: 0, Time elapsed: 0.623 sec [junit] [ERROR] TEST org.apache.torque.util.SqlExpressionTest FAILED .. BUILD FAILED File.. /home/brmiller/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly Element... fail Line.. 181 Column 54 There were test failures. Total time: 17 seconds Finished at: Fri Feb 01 21:19:56 GMT 2008 I went back to 3.3-RC1 and it won't pass the same test either. And I know I've built 3.3-RC1 from source before. It then occurred to me that we moved our development environment to Java 1.6 since then. Rebuilding the torque runtime (3.3-RC3) using Java 1.5 and the tests work just fine. It turns out that the order of the string values tested for in SqlExpressionTest.testBuildInStringObjectSqlEnumbooleanDB is different still in Sun Java 1.6 than 1.3 or 1.4 (for which cases already exist). This list of re-ordered strings is getting a bit hackish, but a simple test for the order presented in jdk 1.6 fixes the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TORQUE-106) Use boolean sql type not bit sql type with MySQL
[ https://issues.apache.org/jira/browse/TORQUE-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538325 ] Thomas Vandahl commented on TORQUE-106: --- I remember a problem with bit columns in the runtime test of Torque against MYSQL-5 which could be solved by using a new MYSQL JDBC driver, version 5.0 or higher. Could you please check if that applies to your case, too? Use boolean sql type not bit sql type with MySQL Key: TORQUE-106 URL: https://issues.apache.org/jira/browse/TORQUE-106 Project: Torque Issue Type: Bug Affects Versions: 3.2 Reporter: Will Glass-Husain Attachments: mysqlpatch.patch In MySQL 5.0.3 the meaning of the BIT data type changed. It used to be equivalent to tinyint(1) but now it is a new bitwise datatype. This means that when Torque generates SQL files with a bit data type (mapped to the Java boolean) it is incorrect. I suggest that Torque map the Torque bit type to the MySQL Boolean type instead when generating SQL. See the reference from the MySQL manual below. http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview.html * BIT[(M)] A bit-field type. M indicates the number of bits per value, from 1 to 64. The default is 1 if M is omitted. This data type was added in MySQL 5.0.3 for MyISAM, and extended in 5.0.5 to MEMORY, InnoDB, and BDB. Before 5.0.3, BIT is a synonym for TINYINT(1). * TINYINT[(M)] [UNSIGNED] [ZEROFILL] A very small integer. The signed range is -128 to 127. The unsigned range is 0 to 255. * BOOL, BOOLEAN These types are synonyms for TINYINT(1). A value of zero is considered false. Non-zero values are considered true: -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TORQUE-95) MapBuilder.vm should have the platform dependency removed
[ https://issues.apache.org/jira/browse/TORQUE-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl reassigned TORQUE-95: Assignee: Thomas Vandahl MapBuilder.vm should have the platform dependency removed - Key: TORQUE-95 URL: https://issues.apache.org/jira/browse/TORQUE-95 Project: Torque Issue Type: Improvement Components: Generator Affects Versions: 3.3-RC2 Reporter: Thomas Vandahl Assignee: Thomas Vandahl Priority: Minor This is more a marker issue to improve the platform independence of Torque. In the OM templates I found that the only point left where platform-dependent code is generated is MapBuilder.vm There, tMap.setPrimaryKeyMethodInfo() is set depending on the selected database platform. If that could be removed/changed, the generated classes would be free of platform dependent code which in turn would allow to switch between database backends without re-generating the OM-classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TORQUE-95) MapBuilder.vm should have the platform dependency removed
[ https://issues.apache.org/jira/browse/TORQUE-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-95. -- Resolution: Fixed Fix Version/s: 3.3-RC3 Fixed in SVN. The decision is now made at runtime. MapBuilder.vm should have the platform dependency removed - Key: TORQUE-95 URL: https://issues.apache.org/jira/browse/TORQUE-95 Project: Torque Issue Type: Improvement Components: Generator Affects Versions: 3.3-RC2 Reporter: Thomas Vandahl Assignee: Thomas Vandahl Priority: Minor Fix For: 3.3-RC3 This is more a marker issue to improve the platform independence of Torque. In the OM templates I found that the only point left where platform-dependent code is generated is MapBuilder.vm There, tMap.setPrimaryKeyMethodInfo() is set depending on the selected database platform. If that could be removed/changed, the generated classes would be free of platform dependent code which in turn would allow to switch between database backends without re-generating the OM-classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TORQUE-97) Exception NoSuchMethodError when using IDBroker with Java 1.4
[ https://issues.apache.org/jira/browse/TORQUE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl reassigned TORQUE-97: Assignee: Thomas Vandahl Exception NoSuchMethodError when using IDBroker with Java 1.4 - Key: TORQUE-97 URL: https://issues.apache.org/jira/browse/TORQUE-97 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 3.3-RC2 Environment: Java 1.4 Reporter: Markus Müller Assignee: Thomas Vandahl I got the exception java.lang.NoSuchMethodError: java.math.BigDecimal.init(I)V at org.apache.torque.oid.IDBroker.getQuantity(IDBroker.java:747) when using Torque Runtime 3.3-RC2 with JDK 1.4. Java 1.5 defines additional BigDecimal constructors, one of them takes an int parameter. Java 1.4 has only a BigDecimal constructor with a double parameter. I presume that the Torque library was compiled with Java 1.5 causing the problem above. Probably the problem of line 747 may be solved with a cast as the following: quantity = new BigDecimal((double) 1); Line 775 of IDBroker.java may be fixed the same way: quantity = new BigDecimal((double) 10); Thanks, Markus -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TORQUE-97) Exception NoSuchMethodError when using IDBroker with Java 1.4
[ https://issues.apache.org/jira/browse/TORQUE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-97. -- Resolution: Fixed Fix Version/s: 3.3-RC3 Fixed in SVN. Exception NoSuchMethodError when using IDBroker with Java 1.4 - Key: TORQUE-97 URL: https://issues.apache.org/jira/browse/TORQUE-97 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 3.3-RC2 Environment: Java 1.4 Reporter: Markus Müller Assignee: Thomas Vandahl Fix For: 3.3-RC3 I got the exception java.lang.NoSuchMethodError: java.math.BigDecimal.init(I)V at org.apache.torque.oid.IDBroker.getQuantity(IDBroker.java:747) when using Torque Runtime 3.3-RC2 with JDK 1.4. Java 1.5 defines additional BigDecimal constructors, one of them takes an int parameter. Java 1.4 has only a BigDecimal constructor with a double parameter. I presume that the Torque library was compiled with Java 1.5 causing the problem above. Probably the problem of line 747 may be solved with a cast as the following: quantity = new BigDecimal((double) 1); Line 775 of IDBroker.java may be fixed the same way: quantity = new BigDecimal((double) 10); Thanks, Markus -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-95) MapBuilder.vm should have the platform dependency removed
MapBuilder.vm should have the platform dependency removed - Key: TORQUE-95 URL: https://issues.apache.org/jira/browse/TORQUE-95 Project: Torque Issue Type: Improvement Components: Generator Affects Versions: 3.3-RC2 Reporter: Thomas Vandahl Priority: Minor This is more a marker issue to improve the platform independence of Torque. In the OM templates I found that the only point left where platform-dependent code is generated is MapBuilder.vm There, tMap.setPrimaryKeyMethodInfo() is set depending on the selected database platform. If that could be removed/changed, the generated classes would be free of platform dependent code which in turn would allow to switch between database backends without re-generating the OM-classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-92) LargeSelect is missing the correctBooleans() call. BasePeer.correctBooleans() must handle defaultTableMap==null
LargeSelect is missing the correctBooleans() call. BasePeer.correctBooleans() must handle defaultTableMap==null --- Key: TORQUE-92 URL: https://issues.apache.org/jira/browse/TORQUE-92 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 3.3-RC2 Environment: PostgreSQL Reporter: Thomas Vandahl Assigned To: Thomas Vandahl Fix For: 3.3-RC3 When using LargeSelect with PostgreSQL, the handling of boolean values in the Criteria fails for BOOLEANINT and BOOLEANCHAR values because the call to correctBooleans() is missing. To use this, the call of BasePeer.correctBooleans(criteria, tableMap) must gracefully handle the case of tablemap == null, because we don't have access to a decent tableMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TORQUE-91) Index-column size attribute is documented but does not work
[ https://issues.apache.org/jira/browse/TORQUE-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490954 ] Thomas Vandahl commented on TORQUE-91: -- I can live with 1), anytime. The point is, documented attributes/elements should work or the attribute including docs should be removed, there is no in between. I found that most of the databases I checked do not support limiting the size of an index column directly, everything else is vendor specific. So basically, +1 for removing said attribute from the schema. Index-column size attribute is documented but does not work --- Key: TORQUE-91 URL: https://issues.apache.org/jira/browse/TORQUE-91 Project: Torque Issue Type: Bug Components: Generator Affects Versions: 3.3-RC2 Reporter: Thomas Vandahl Priority: Minor The database schema allows a size attribute for the index-column element which did not make it into neither the Index code nor the templates. Some databases support this parameter, however (namely MySQL). The attribute should be utilized where supported by the database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-91) Index-column size attribute is documented but does not work
Index-column size attribute is documented but does not work --- Key: TORQUE-91 URL: https://issues.apache.org/jira/browse/TORQUE-91 Project: Torque Issue Type: Bug Components: Generator Affects Versions: 3.3-RC2 Reporter: Thomas Vandahl Priority: Minor The database schema allows a size attribute for the index-column element which did not make it into neither the Index code nor the templates. Some databases support this parameter, however (namely MySQL). The attribute should be utilized where supported by the database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TORQUE-68) DatabaseMap remains empty if Torque is stopped and restarted, causes NPEs
[ https://issues.apache.org/jira/browse/TORQUE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-68. -- Resolution: Fixed Fix Version/s: (was: 3.3) 3.3-RC3 Hopefully last attempt to fix this. A test case has been created which fails before and passes after the fix. What more can you ask... :-) DatabaseMap remains empty if Torque is stopped and restarted, causes NPEs - Key: TORQUE-68 URL: https://issues.apache.org/jira/browse/TORQUE-68 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 3.3-RC2 Environment: Avalon, JUnit-Tests Reporter: Thomas Vandahl Assigned To: Thomas Vandahl Fix For: 3.3-RC3 When running tests with the Fulcrum-Testcontainer, the TorqueComponent is instantiated on every lookup (setUp()) and shutdown on every tearDown(). In this scenario the first test succeeds and all others fail because the DatabaseMap contains no tables. This is probably caused by invalid static references to the DatabaseMap of the previous instance. This situation causes NullPointerExceptions in several BasePeer methods(e.g. processTables()). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TORQUE-76) broken combatibility to 3.2: incompatible types error when compiling BasePeer classes
[ https://issues.apache.org/jira/browse/TORQUE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed TORQUE-76. broken combatibility to 3.2: incompatible types error when compiling BasePeer classes - Key: TORQUE-76 URL: https://issues.apache.org/jira/browse/TORQUE-76 Project: Torque Issue Type: Bug Components: Generator Affects Versions: 3.3-RC1 Reporter: Ronny Völker Assigned To: Thomas Vandahl Fix For: 3.3 Attachments: torque-76-testcase.zip When compiling Scarab with Torque3.3rc1 lots of incompatible types error are returned. When compiling with Torque3.2 everything is compiled successfully. The root cause are changes of torque/templates/trunk/src/templates/om/Peer.vm in r373352. In this revisions some class casts have been removed which seem to be required in BasePeer classes, if inheritance and interfaces are used in the schema mapping. Sample compilation output: [javac] C:\elaxy\svn\scarab_trunk\src\java\org\tigris\scarab\om\BaseIssuePeer.java:933: incompatible types [javac] found : org.tigris.scarab.om.Module [javac] required: org.tigris.scarab.om.ScarabModule [javac] ScarabModule temp_obj2 = temp_obj1.getModule(); The buggy line using Torque3.3rc1 templates: Issue temp_obj1 = (Issue) results.get(j); ScarabModule temp_obj2 = temp_obj1.getModule(); The sameline using Torque3.2 templates: Issue temp_obj1 = (Issue) results.get(j); ScarabModule temp_obj2 = (ScarabModule)temp_obj1.getModule(); The interface of Issue.getModule() (inherited from BaseIssue): public Module getModule() The related sections in the schema.xml of Scarab: table name=SCARAB_MODULE idMethod=idbroker javaName=ScarabModule baseClass=org.tigris.scarab.om.AbstractScarabModule interface=Module ... table name=SCARAB_ISSUE idMethod=idbroker javaName=Issue ... column name=MODULE_ID required=true type=INTEGER/column foreign-key foreignTable=SCARAB_MODULE reference local=MODULE_ID foreign=MODULE_ID/ /foreign-key ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TORQUE-77) Generator ant task ignores torque.subpackage.* properties
[ https://issues.apache.org/jira/browse/TORQUE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed TORQUE-77. Fixed in 3.3-RC2 Generator ant task ignores torque.subpackage.* properties - Key: TORQUE-77 URL: https://issues.apache.org/jira/browse/TORQUE-77 Project: Torque Issue Type: Bug Components: Generator Affects Versions: 3.3-RC1 Reporter: Jonathan Purvis Assigned To: CG Monroe Priority: Critical The ant task for the generator does not pass on any of the torque.subpackage.* properties to the Velocity templates. So the classes end up being generated for the wrong package. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TORQUE-76) broken combatibility to 3.2: incompatible types error when compiling BasePeer classes
[ https://issues.apache.org/jira/browse/TORQUE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-76. -- Resolution: Fixed Fix Version/s: (was: 4.0) Fixed in SVN. Ronny, would you please check out the latest trunk to make sure everything works ok? broken combatibility to 3.2: incompatible types error when compiling BasePeer classes - Key: TORQUE-76 URL: https://issues.apache.org/jira/browse/TORQUE-76 Project: Torque Issue Type: Bug Components: Generator Affects Versions: 3.3-RC1 Reporter: Ronny Völker Assigned To: Thomas Vandahl Fix For: 3.3 Attachments: torque-76-testcase.zip When compiling Scarab with Torque3.3rc1 lots of incompatible types error are returned. When compiling with Torque3.2 everything is compiled successfully. The root cause are changes of torque/templates/trunk/src/templates/om/Peer.vm in r373352. In this revisions some class casts have been removed which seem to be required in BasePeer classes, if inheritance and interfaces are used in the schema mapping. Sample compilation output: [javac] C:\elaxy\svn\scarab_trunk\src\java\org\tigris\scarab\om\BaseIssuePeer.java:933: incompatible types [javac] found : org.tigris.scarab.om.Module [javac] required: org.tigris.scarab.om.ScarabModule [javac] ScarabModule temp_obj2 = temp_obj1.getModule(); The buggy line using Torque3.3rc1 templates: Issue temp_obj1 = (Issue) results.get(j); ScarabModule temp_obj2 = temp_obj1.getModule(); The sameline using Torque3.2 templates: Issue temp_obj1 = (Issue) results.get(j); ScarabModule temp_obj2 = (ScarabModule)temp_obj1.getModule(); The interface of Issue.getModule() (inherited from BaseIssue): public Module getModule() The related sections in the schema.xml of Scarab: table name=SCARAB_MODULE idMethod=idbroker javaName=ScarabModule baseClass=org.tigris.scarab.om.AbstractScarabModule interface=Module ... table name=SCARAB_ISSUE idMethod=idbroker javaName=Issue ... column name=MODULE_ID required=true type=INTEGER/column foreign-key foreignTable=SCARAB_MODULE reference local=MODULE_ID foreign=MODULE_ID/ /foreign-key ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TORQUE-79) TorqueInstance.getConnection should throw an interpretable error message if Torque is not initialized
[ https://issues.apache.org/jira/browse/TORQUE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467274 ] Thomas Vandahl commented on TORQUE-79: -- As far as I can tell, all access to the TorqueInstance goes thru Torque.getInstance(), doesn't it? Wouldn't it be better to place the check there? Maybe one could start initialization automatically, there are places inside Torque where something similar is already done. What do you think? TorqueInstance.getConnection should throw an interpretable error message if Torque is not initialized - Key: TORQUE-79 URL: https://issues.apache.org/jira/browse/TORQUE-79 Project: Torque Issue Type: Improvement Components: Runtime Affects Versions: 3.3-RC1 Reporter: Thomas Fischer Assigned To: Thomas Fischer Priority: Trivial Fix For: 4.0 From the users mailing list, if Torque.getConection() is called and Torque is not initiialized, the error message is now java.lang.NullPointerException: There was no DataSourceFactory configured for the connection XXX at org.apache.torque.TorqueInstance.getConnection(TorqueInstance.java:711) at org.apache.torque.Torque.getConnection(Torque.java:268) at org.apache.torque.util.Transaction.beginOptional(Transaction.java:80) at org.apache.torque.util.Transaction.begin(Transaction.java:62) . There should be a check whether Torque is initialized, and an exception thrown which says that Torque is not initialized if it is not. This issue does not block the release of Torque-3.3-RC2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TORQUE-76) broken combatibility to 3.2: incompatible types error when compiling BasePeer classes
[ https://issues.apache.org/jira/browse/TORQUE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl reassigned TORQUE-76: Assignee: Thomas Vandahl broken combatibility to 3.2: incompatible types error when compiling BasePeer classes - Key: TORQUE-76 URL: https://issues.apache.org/jira/browse/TORQUE-76 Project: Torque Issue Type: Bug Components: Generator Affects Versions: 3.3-RC1 Reporter: Ronny Völker Assigned To: Thomas Vandahl Fix For: 3.3, 4.0 When compiling Scarab with Torque3.3rc1 lots of incompatible types error are returned. When compiling with Torque3.2 everything is compiled successfully. The root cause are changes of torque/templates/trunk/src/templates/om/Peer.vm in r373352. In this revisions some class casts have been removed which seem to be required in BasePeer classes, if inheritance and interfaces are used in the schema mapping. Sample compilation output: [javac] C:\elaxy\svn\scarab_trunk\src\java\org\tigris\scarab\om\BaseIssuePeer.java:933: incompatible types [javac] found : org.tigris.scarab.om.Module [javac] required: org.tigris.scarab.om.ScarabModule [javac] ScarabModule temp_obj2 = temp_obj1.getModule(); The buggy line using Torque3.3rc1 templates: Issue temp_obj1 = (Issue) results.get(j); ScarabModule temp_obj2 = temp_obj1.getModule(); The sameline using Torque3.2 templates: Issue temp_obj1 = (Issue) results.get(j); ScarabModule temp_obj2 = (ScarabModule)temp_obj1.getModule(); The interface of Issue.getModule() (inherited from BaseIssue): public Module getModule() The related sections in the schema.xml of Scarab: table name=SCARAB_MODULE idMethod=idbroker javaName=ScarabModule baseClass=org.tigris.scarab.om.AbstractScarabModule interface=Module ... table name=SCARAB_ISSUE idMethod=idbroker javaName=Issue ... column name=MODULE_ID required=true type=INTEGER/column foreign-key foreignTable=SCARAB_MODULE reference local=MODULE_ID foreign=MODULE_ID/ /foreign-key ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TORQUE-68) DatabaseMap remains empty if Torque is stopped and restarted, causes NPEs
[ http://issues.apache.org/jira/browse/TORQUE-68?page=comments#action_12459268 ] Thomas Vandahl commented on TORQUE-68: -- I strongly believe that the reinstantiation of the component should work without any copying. If I start a new instance of Torque, no matter if in Avalon mode or not, I would expect everything to be as clean as if I started the first instance. This, in turn, means that we need to remove all static references in static classes to runtime-dependent objects. DatabaseMap remains empty if Torque is stopped and restarted, causes NPEs - Key: TORQUE-68 URL: http://issues.apache.org/jira/browse/TORQUE-68 Project: Torque Issue Type: Bug Components: Runtime, Generator Affects Versions: 3.3 Environment: Avalon, JUnit-Tests Reporter: Thomas Vandahl When running tests with the Fulcrum-Testcontainer, the TorqueComponent is instantiated on every lookup (setUp()) and shutdown on every tearDown(). In this scenario the first test succeeds and all others fail because the DatabaseMap contains no tables. This is probably caused by invalid static references to the DatabaseMap of the previous instance. This situation causes NullPointerExceptions in several BasePeer methods(e.g. processTables()). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TORQUE-73) Missing log4j.jar for Torque Generator?
[ http://issues.apache.org/jira/browse/TORQUE-73?page=comments#action_12456975 ] Thomas Vandahl commented on TORQUE-73: -- I'd add the log4j.jar. The Torque generator has no other Avalon dependencies and log4j is quite common in other projects. Missing log4j.jar for Torque Generator? --- Key: TORQUE-73 URL: http://issues.apache.org/jira/browse/TORQUE-73 Project: Torque Issue Type: Bug Components: Generator Affects Versions: 3.3 Environment: Windows XP Reporter: Joerg Friedrich 1. I have downloaded the Torque 3.3 (RC1) Generator package. 2. I want to run the jdbc target; I set all properties as required in the build.properties file 3. I set my ANT_HOME and JAVA_HOME (ANT 1.6.4 from Eclipse, JDK 1.5) 4. I execute ant -f build-torque.xml jdbc (actually, any other target has the same problem) 5. I receive a velocity error 6. I install log4j.jar into the lib directory 7. It works! Maybe I am missing something, and it should work without log4j, but in my environment it does not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TORQUE-2) Torque plugin for Maven 2
[ http://issues.apache.org/jira/browse/TORQUE-2?page=all ] Thomas Vandahl closed TORQUE-2. --- Torque plugin for Maven 2 - Key: TORQUE-2 URL: http://issues.apache.org/jira/browse/TORQUE-2 Project: Torque Issue Type: New Feature Components: Maven-Plugin Affects Versions: 3.1.1, 3.2 Reporter: Raphaël Piéroni Assigned To: Thomas Fischer Fix For: 3.3 Attachments: maven2-plugin.jar, maven_log_file.txt, torque-maven-plugin.tgz Here is an archive (tgz) of a first draft of a maven 2 plugin for using torque with some of the features of the torque plugin for maven 1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TORQUE-5) Mapping of INTEGER to MEDIUMINT for MySQL?
[ http://issues.apache.org/jira/browse/TORQUE-5?page=all ] Thomas Vandahl closed TORQUE-5. --- Mapping of INTEGER to MEDIUMINT for MySQL? -- Key: TORQUE-5 URL: http://issues.apache.org/jira/browse/TORQUE-5 Project: Torque Issue Type: Improvement Components: Generator Affects Versions: 3.2 Reporter: Joerg Friedrich Assigned To: Thomas Fischer Priority: Minor Fix For: 3.3 With Torque 3.2, the XML schema data type INTEGER is mapped to MEDIUMINT, while it has been INTEGER in earlier generator releases. It may be better to revert to the old mapping. The MySQL documentation states that the data range for MEDIUMINT is 2^24 while that of INTEGER is 2^32. This can matter when using INTEGER as object ids. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TORQUE-6) Generator does not generate foreign key constraints for Interbase/Firebird
[ http://issues.apache.org/jira/browse/TORQUE-6?page=all ] Thomas Vandahl closed TORQUE-6. --- Generator does not generate foreign key constraints for Interbase/Firebird -- Key: TORQUE-6 URL: http://issues.apache.org/jira/browse/TORQUE-6 Project: Torque Issue Type: Bug Components: Generator Affects Versions: 3.2 Reporter: Joerg Friedrich Assigned To: Thomas Fischer Fix For: 3.3 The generator does not generate foreign key constraints for Interbase/Firebird. This could probably be easily fixed by adding a file foreignkey.vm to the sql/base/interbase directory in the templates jar (torque-gen-templates-3.2.jar) containing this: #foreach ($fk in $table.ForeignKeys) FOREIGN KEY ($fk.LocalColumnNames) REFERENCES $fk.ForeignTableName ($fk.ForeignColumnNames), #end -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TORQUE-10) doSelectJoinYYY in Oracle fails with limit/offset and same column names
[ http://issues.apache.org/jira/browse/TORQUE-10?page=all ] Thomas Vandahl closed TORQUE-10. doSelectJoinYYY in Oracle fails with limit/offset and same column names Key: TORQUE-10 URL: http://issues.apache.org/jira/browse/TORQUE-10 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 3.2 Environment: Oracle Reporter: Thomas Fischer Assigned To: Thomas Fischer Fix For: 3.3 Reported by Bouvet Konsulent: If a criteria with a limit or Offset is used in XXXPeer.doSelectJoinYYY(Criteria), and the Tables XXX and YYY have columns with same names, the method fails with a ORA-00918: column ambiguously defined. This is because the select * from the limit/offset query clashes with the two same names in the inner select clause. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
