[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] [Resolved] (TORQUE-354) Add doSelectAsStream() to BasePeerImpl
[ https://issues.apache.org/jira/browse/TORQUE-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-354. --- Resolution: Implemented Implemented in SVN > 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 >Priority: Major > 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] [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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=15334234#comment-15334234
]
Thomas Vandahl edited comment on TORQUE-343 at 6/16/16 6:16 PM:
Yes I know about the extensibility. The use case I have in mind is the
extension of persistent classes in a library like in Fulcrum Security. You are
supposed to extend e.g. user objects to match your requirements. Right now, we
always need to configure the OM class *and* its Peer class to handle this case.
It would be easier to query the Torque instance for the PeerImpl class for a
given OM class.
Another use case I found are complex queries. I found it very useful to define
separate (non-generated) PeerImpl/RecordMapper classes to handle complex joins
within custom-built objects. In the end I found myself creating those PeerImpl
object instances over and over again because I had no real place to store them.
This is normally not necessary as these objects are thread safe.
If BasePeerImpl were abstract, doSelect(obj), doInsert(obj), doUpdate(obj),
doDelete(obj) and friends could be moved to BasePeerImpl and less code would be
generated. Perhaps we introduce an abstract class derived from BasePeerImpl as
a base class to the generated PeerImpl classes to make use of this fact. Then,
an abstract method buildCriteria() could be placed there.
was (Author: tv):
Yes I know about the extensibility. The use case I have in mind is the
extension of persistent classes in a library like in Fulcrum Security. You are
supposed to extend e.g. user objects to match your requirements. Right now, we
always need to configure the OM class *and* its Peer class to handle this case.
It would be easier to query the Torque instance for the PeerImpl class for a
given OM class.
Another use case I found are complex queries. I found it very useful to define
separate (non-generated) PeerImpl/RecordMapper classes to handle complex joins
within custom-built objects. In the end I found myself up creating those
PeerImpl object instances over and over again because I had no real place to
store them. This is normally not necessary as these objects are thread safe.
to be continued...
> Implement a central registry for peerImpls like the registry for managers
> -
>
> Key: TORQUE-343
> URL: https://issues.apache.org/jira/browse/TORQUE-343
> Project: Torque
> Issue Type: Improvement
> Components: Runtime, Templates
>Affects Versions: 4.0
>Reporter: Thomas Vandahl
>Assignee: Thomas Vandahl
> Fix For: 4.1
>
>
> I'd like to suggest a central registry for peerImpl-objects which can be
> queried by the Persistent class it is responsible for. This would allow
> reusing and extending the peer objects dynamically as well as giving them
> some kind of life-cycle.
> The main method would be similar to this:
> {code:java}
> public BasePeerImpl getPeerFor(Class persistentClass)
> {
> return peerRegistry.get(persistentClass);
> }
> {code}
> I would also like to suggest moving the buildCriteria(obj) method to the
> RecordMapper or the TableMap class. This will further reduce the amount of
> code that needs to be generated.
> If the idea is received well, I'll come up with a proposal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-343) Implement a central registry for peerImpls like the registry for managers
[
https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15334234#comment-15334234
]
Thomas Vandahl commented on TORQUE-343:
---
Yes I know about the extensibility. The use case I have in mind is the
extension of persistent classes in a library like in Fulcrum Security. You are
supposed to extend e.g. user objects to match your requirements. Right now, we
always need to configure the OM class *and* its Peer class to handle this case.
It would be easier to query the Torque instance for the PeerImpl class for a
given OM class.
Another use case I found are complex queries. I found it very useful to define
separate (non-generated) PeerImpl/RecordMapper classes to handle complex joins
within custom-built objects. In the end I found myself up creating those
PeerImpl object instances over and over again because I had no real place to
store them. This is normally not necessary as these objects are thread safe.
to be continued...
> Implement a central registry for peerImpls like the registry for managers
> -
>
> Key: TORQUE-343
> URL: https://issues.apache.org/jira/browse/TORQUE-343
> Project: Torque
> Issue Type: Improvement
> Components: Runtime, Templates
>Affects Versions: 4.0
>Reporter: Thomas Vandahl
>Assignee: Thomas Vandahl
> Fix For: 4.1
>
>
> I'd like to suggest a central registry for peerImpl-objects which can be
> queried by the Persistent class it is responsible for. This would allow
> reusing and extending the peer objects dynamically as well as giving them
> some kind of life-cycle.
> The main method would be similar to this:
> {code:java}
> public BasePeerImpl getPeerFor(Class persistentClass)
> {
> return peerRegistry.get(persistentClass);
> }
> {code}
> I would also like to suggest moving the buildCriteria(obj) method to the
> RecordMapper or the TableMap class. This will further reduce the amount of
> code that needs to be generated.
> If the idea is received well, I'll come up with a proposal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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] [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: > > > Apache XYZ > 2015-02-16 > 1.6.2 > > > > > Apache XYZ > 2014-09-24 > 1.6.1 > > > 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] [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: > > > Apache XYZ > 2015-02-16 > 1.6.2 > > > > > Apache XYZ > 2014-09-24 > 1.6.1 > > > 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-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] [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-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] [Commented] (TORQUE-250) Fix documentation issues
[
https://issues.apache.org/jira/browse/TORQUE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-250) Fix documentation issues
[
https://issues.apache.org/jira/browse/TORQUE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-203) Quote table names in creation
[ https://issues.apache.org/jira/browse/TORQUE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-203) Quote table names in creation
[ https://issues.apache.org/jira/browse/TORQUE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274733#comment-13274733 ] Thomas Vandahl commented on TORQUE-203: --- Maybe this issue should be generalized a bit. Is it actually doable to keep a list of reserved words for each supported DBMS? We regularly run into the problem that identifiers that are perfectly legal in MySQL cause Oracle to barf. I don't think that quoting is a good solution unless it is provided at all places in the generator and the runtime. As an alternative, the generator could issue a warning like "identifier is a reserved word for Oracle". WDYT? > 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-165) Implement cascading deletes
[ https://issues.apache.org/jira/browse/TORQUE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066010#comment-13066010 ] Thomas Vandahl commented on TORQUE-165: --- Well, in my book cascading deletes would be the task of the database. It knows best what to do. Don't you think we should drop this as a feature? I never understood why it was there in the first place. Torque only knows about cascades based on foreign keys anyway. Besides, to be exact, it would be necessary to consider the value of onDelete when implementing this. > Implement cascading deletes > --- > > Key: TORQUE-165 > URL: https://issues.apache.org/jira/browse/TORQUE-165 > Project: Torque > Issue Type: Improvement >Reporter: Thomas Fox >Assignee: Thomas Fox > > If the flag criteria.cascade is set to true and a detelete() method is called > on a peer class, all rows ehich are referenced by the deleted rows should be > deleted as well, including rows which are referenced indirectly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-163) Map builders are emptied on Torque.shutdown() and not rebuilt on subsequent init()
[ https://issues.apache.org/jira/browse/TORQUE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066004#comment-13066004 ] Thomas Vandahl commented on TORQUE-163: --- Agreed. The general idea of the Avalon lifecycle contract is the symmetry of initialize/dispose, start/stop etc. So the requirement would be that dispose() or shutdown() left the component or instance in the same state as it was before the first initialize() or init(). Clearly this doesn't work the way Torque is designed right now. Nevertheless, my humble opinion is that we should strive to remove as much static stuff as possible from Torque to reach that goal one day. A clean lifecycle is a Good Thing(TM), be it Avalon or not. > Map builders are emptied on Torque.shutdown() and not rebuilt on subsequent > init() > -- > > Key: TORQUE-163 > URL: https://issues.apache.org/jira/browse/TORQUE-163 > Project: Torque > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Thomas Fox >Assignee: Thomas Fox > > Problem: After a shutdown() and init() of Torque, the Map Builder cache > entries which have been present before shutdown are not present anymore after > a new init. > Analysis: If a Peer class is loaded, it registers its map builder and the > MapBuilder is built immediately or on Torque initialisation, depending on > whether Torque is initialized or not. > On Torque.shutdown(), all known map builders are removed. > On a new init(), these Map builders will not be rebuilt anew because the Peer > class will not be loaded a second time. > Solution: The Map Builder cache entries should not be removed on > Torque.shutdown() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-163) Map builders are emptied on Torque.shutdown() and not rebuilt on subsequent init()
[ https://issues.apache.org/jira/browse/TORQUE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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);
> 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 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);
> 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 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] 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
>
>
>
>
>
>
> 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-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 closed TORQUE-36. Fixed in village-3.3.1 > 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. 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] 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] Resolved: (TORQUE-1) Equal tablenames in different databases can lead to errors
[ https://issues.apache.org/jira/browse/TORQUE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-1. - Resolution: Won't Fix Fix Version/s: 4.0 Assignee: Thomas Vandahl (was: Thomas Fox) Village will be removed in Version 4.0 of Torque, so this should be accepted be a permanent restriction of Village. > Equal tablenames in different databases can lead to errors > -- > > Key: TORQUE-1 > URL: https://issues.apache.org/jira/browse/TORQUE-1 > 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: 4.0 > > > If more than one database is accessed on runtime, and there are tables in > different databases which have the same name but a different structure, no > datasets can be written to one of the tables. > Reason is that village retrieves information about tables via jdbc, and > caches this information. In the cache, the tablename is used as key. Once a > table is accessed, the information is cached. If another table with the same > name is accessed, wrong information is retrieved from the cache, which leads > to errors. -- 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-1) Equal tablenames in different databases can lead to errors
[ https://issues.apache.org/jira/browse/TORQUE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926738#action_12926738 ] Thomas Vandahl commented on TORQUE-1: - The cache key for this data is built from the jdbc-URL and the table name. So for all URLs carrying the database name this should not be an issue. For all others, this problem remains. > Equal tablenames in different databases can lead to errors > -- > > Key: TORQUE-1 > URL: https://issues.apache.org/jira/browse/TORQUE-1 > Project: Torque > Issue Type: Bug > Components: Runtime, Village >Affects Versions: 3.0, 3.1, 3.1.1, 3.2 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.0 > > > If more than one database is accessed on runtime, and there are tables in > different databases which have the same name but a different structure, no > datasets can be written to one of the tables. > Reason is that village retrieves information about tables via jdbc, and > caches this information. In the cache, the tablename is used as key. Once a > table is accessed, the information is cached. If another table with the same > name is accessed, wrong information is retrieved from the cache, which leads > to errors. -- 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] 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] Assigned: (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 reassigned TORQUE-152:
-
Assignee: Thomas Vandahl
> 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
>
> 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 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-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&focusedCommentId=12924208#action_12924208
]
Thomas Vandahl commented on TORQUE-152:
---
Would you please try to check out the current trunk of Village and see if this
issue still applies? I made a couple of changes recently and I remember
something similar being addressed.
> 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
> Fix For: 3.3
>
> 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 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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=12907916#action_12907916 ] Thomas Vandahl commented on TORQUE-128: --- I tend to disagree. If I'm not mislead, I can have columns which are primary keys but have no auto-increment flag on (or no associated sequence, for that matter). N:M-tables are a typical example or tables with compound primary keys. How would you handle those? As I see it, this modification would impose a serious limitation on the way you describe database schemas with Torque. Besides, Torque handles sequences just fine with database systems that support them. > 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-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] 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] 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-tabpanel&focusedCommentId=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] 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] 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-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-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] 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-tabpanel&focusedCommentId=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.(TexenTaskMojo.java:109) > at > org.apache.torque.mojo.DataModelTaskMojo.(DataModelTaskMojo.java:111) > at org.apache.torque.mojo.OMMojo.(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
[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] 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] 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] 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-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-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.(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] 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.(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] Resolved: (TORQUE-92) LargeSelect is missing the correctBooleans() call. BasePeer.correctBooleans() must handle defaultTableMap==null
[ https://issues.apache.org/jira/browse/TORQUE-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TORQUE-92. -- Resolution: Fixed Added the call to BasePeer.correctBooleans() to LargeSelect. Fixed the handling of unqualified column names in BasePeer.correctBooleans(), Gracefully handle the case of a defaultTableMap==null, Added testCases to verify the behaviour. > 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] 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-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] Updated: (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 updated TORQUE-68: - Component/s: (was: Generator) Fix Version/s: (was: 3.3-RC2) 3.3 Affects Version/s: (was: 3.3) 3.3-RC2 > 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 > > > 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]
