[jira] [Commented] (TORQUE-364) RecordMapper very slow on many columns in table

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt commented on TORQUE-364:
---

Maybe we could add a switch (torque.om.simpleMapping or smth like that) which 
enables this workaround?
{code:java}
if (criteria == null || criteria.getSelectColumns().size() - offset == 
BaseXXXPeer.numColumns)
{code}

Default: false
Notice: if joining tables could lead to unexpected behaviour?


> RecordMapper very slow on many columns in table
> ---
>
> Key: TORQUE-364
> URL: https://issues.apache.org/jira/browse/TORQUE-364
> Project: Torque
>  Issue Type: Improvement
>  Components: Runtime, Templates
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: criteria_api, om, performance, recordmapper, templates
> Fix For: 6.0
>
>
> When "doSelect()" a large quantity of columns in a table the default 
> RecordMappers generated by Om-Templates (processRow()) cause an  
> !https://wikimedia.org/api/rest_v1/media/math/render/svg/4441d9689c0e6b2c47994e2f587ac5378faeefba!
>  Problem. (technically O(rows * columns))
> Specifically, constantly generating the SQL expression of all possible 
> columns for every row in the result causes excessive use of StringBuilders 
> which slow the mapping process to a crawl.
> I currently have two ideas on how best to tackle this problem:
>  # Either generate all SQL column expressions once when a (template 
> generated) RecordMapper is first created (using final static String fields) 
> thus reducing the cost for every row to generating all selected column SQL 
> expressions  once(instead of every selected column times every available 
> column)
>  # Or (in case the first approach generates unacceptably excessive number of 
> fields for RecordMappers) adjust the RecordMapper API to allow a 
> "prepare(Criteria, int offset)" method to be called once before processing 
> any rows and implement it on generated RecordMappers to scan the Criteria and 
> build two lists: One containing references to the setXXX methods of the 
> mapper in the order they appear in the ResultSet (via the order in the 
> Criteria) and a second list containing the corresponding column offsets. This 
> would allow the processRow method to only iterated over both lists 
> simultaneously and call the referenced methods with the result set and offset 
> immediately. (Alternatively one list using lambdas could be used but I am 
> currently not sure about the stance or impact of these lambdas in the Torque 
> project.)
> credits to [~refarb] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (TORQUE-364) RecordMapper very slow on many columns in table

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt commented on TORQUE-364:
---

The integrated code is correct as I can see for now.

As the MappingStrategy is regenerated everytime a new row is processed, this 
fix is sadly not doing anything for the performance.

However its working and we can use it for a future performance fix e.g. by 
making it reusable by saving it with the criteria or somewhere appropriate.

 

[~refarb] [~mwriedt]

 

 

> RecordMapper very slow on many columns in table
> ---
>
> Key: TORQUE-364
> URL: https://issues.apache.org/jira/browse/TORQUE-364
> Project: Torque
>  Issue Type: Improvement
>  Components: Runtime, Templates
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: criteria_api, om, performance, recordmapper, templates
>
> When "doSelect()" a large quantity of columns in a table the default 
> RecordMappers generated by Om-Templates (processRow()) cause an  
> !https://wikimedia.org/api/rest_v1/media/math/render/svg/4441d9689c0e6b2c47994e2f587ac5378faeefba!
>  Problem. (technically O(rows * columns))
> Specifically, constantly generating the SQL expression of all possible 
> columns for every row in the result causes excessive use of StringBuilders 
> which slow the mapping process to a crawl.
> I currently have two ideas on how best to tackle this problem:
>  # Either generate all SQL column expressions once when a (template 
> generated) RecordMapper is first created (using final static String fields) 
> thus reducing the cost for every row to generating all selected column SQL 
> expressions  once(instead of every selected column times every available 
> column)
>  # Or (in case the first approach generates unacceptably excessive number of 
> fields for RecordMappers) adjust the RecordMapper API to allow a 
> "prepare(Criteria, int offset)" method to be called once before processing 
> any rows and implement it on generated RecordMappers to scan the Criteria and 
> build two lists: One containing references to the setXXX methods of the 
> mapper in the order they appear in the ResultSet (via the order in the 
> Criteria) and a second list containing the corresponding column offsets. This 
> would allow the processRow method to only iterated over both lists 
> simultaneously and call the referenced methods with the result set and offset 
> immediately. (Alternatively one list using lambdas could be used but I am 
> currently not sure about the stance or impact of these lambdas in the Torque 
> project.)
> credits to [~refarb] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
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-364) RecordMapper very slow on many columns in table

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt edited comment on TORQUE-364 at 5/4/24 10:23 PM:


The integrated code is correct as I can see for now.

As the MappingStrategy is regenerated everytime a new row is processed, this 
fix is sadly not doing anything for the performance.

However its working and we can use it for a future performance fix e.g. by 
making it reusable by saving it with the criteria or somewhere appropriate.

 

[~refarb] [~mwriedt]


was (Author: JIRAUSER299058):
The integrated code is correct as I can see for now.

As the MappingStrategy is regenerated everytime a new row is processed, this 
fix is sadly not doing anything for the performance.

However its working and we can use it for a future performance fix e.g. by 
making it reusable by saving it with the criteria or somewhere appropriate.

 

[~refarb] [~mwriedt]

 

 

> RecordMapper very slow on many columns in table
> ---
>
> Key: TORQUE-364
> URL: https://issues.apache.org/jira/browse/TORQUE-364
> Project: Torque
>  Issue Type: Improvement
>  Components: Runtime, Templates
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: criteria_api, om, performance, recordmapper, templates
>
> When "doSelect()" a large quantity of columns in a table the default 
> RecordMappers generated by Om-Templates (processRow()) cause an  
> !https://wikimedia.org/api/rest_v1/media/math/render/svg/4441d9689c0e6b2c47994e2f587ac5378faeefba!
>  Problem. (technically O(rows * columns))
> Specifically, constantly generating the SQL expression of all possible 
> columns for every row in the result causes excessive use of StringBuilders 
> which slow the mapping process to a crawl.
> I currently have two ideas on how best to tackle this problem:
>  # Either generate all SQL column expressions once when a (template 
> generated) RecordMapper is first created (using final static String fields) 
> thus reducing the cost for every row to generating all selected column SQL 
> expressions  once(instead of every selected column times every available 
> column)
>  # Or (in case the first approach generates unacceptably excessive number of 
> fields for RecordMappers) adjust the RecordMapper API to allow a 
> "prepare(Criteria, int offset)" method to be called once before processing 
> any rows and implement it on generated RecordMappers to scan the Criteria and 
> build two lists: One containing references to the setXXX methods of the 
> mapper in the order they appear in the ResultSet (via the order in the 
> Criteria) and a second list containing the corresponding column offsets. This 
> would allow the processRow method to only iterated over both lists 
> simultaneously and call the referenced methods with the result set and offset 
> immediately. (Alternatively one list using lambdas could be used but I am 
> currently not sure about the stance or impact of these lambdas in the Torque 
> project.)
> credits to [~refarb] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (TORQUE-364) RecordMapper very slow on many columns in table

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt commented on TORQUE-364:
---

To point 3. we finally got a slightly nicer working prototype to share;
{code:java}
### recordMapperBase.vm
---+
// at the top import the new runtime MappingStrategy class
import org.apache.torque.om.mapper.MappingStrategy;
---
---+
// Should this be cached per RecordMapper (Thread safety/Multi query safety?)
private MappingStrategy<${dbObjectClassName}> strategy;

// A sample prepareStrategy implementation, still missing the new HashSet 
optimization!
public MappingStrategy<${dbObjectClassName}> prepareStrategy(Criteria criteria, 
int offset)
{
MappingStrategy<${dbObjectClassName}> strategy = new 
MappingStrategy<${dbObjectClassName}>();
if (criteria == null)
{
return strategy;
}

int nextOuterOffset = offset + 1;
List selectColumns = criteria.getSelectColumns();
List columnsWithoutOffset = selectColumns.subList(
offset,
selectColumns.size());

for (Column column : columnsWithoutOffset)
{
// Create a final local copy for this iteration to be passed into the 
lambdas
final int nextOffset = nextOuterOffset;
String columnExpression = column.getSqlExpression();
#set ( $else = "" )
#foreach ($columnElement in $torqueGen.getChildren("column"))
#set ( $setter = $columnElement.getAttribute("setter") )
#set ( $getter = $columnElement.getAttribute("getter") )
#set ( $peerColumnName = $columnElement.getAttribute("peerColumnName") )
#set ( $fieldType = $columnElement.getAttribute("fieldType") )
${else}if (${peerColumnName}_EXPRESSION.equals(columnExpression))
{
strategy.addColumn(nextOffset, (res, inst) -> 
inst.${setter}(this.${getter}(res, nextOffset)));
}
#set ( $else = "else ")
#end
nextOuterOffset += 1;
}
strategy.finish($torqueGen.getChildren("column").size());
return strategy;
}
---
---+
// in processRow()
// this could theoretically replace BOTh if cases (criteria == null AND != 
null)
// However criteria == null might still be slightly faster than this!

// Wherever the MappingStrategy is ultimately stored should probably handle 
invalidation
// Storing it in Criteria for example would allow invalidating whenever a 
select columns is added/modified
//  However, for testing purposes we just placed it directly in processRow 
to show viability.
if (this.strategy == null) {
this.strategy = prepareStrategy(criteria, offset);
}
this.strategy.execute(resultSet, $field);
---


### MappingStrategy.java

package org.apache.torque.om.mapper;

import org.apache.commons.lang3.tuple.Pair;
import org.apache.commons.lang3.function.FailableBiConsumer;
import org.apache.torque.TorqueException;

import java.sql.ResultSet;
import java.util.ArrayList;
import java.util.Comparator;
import java.util.List;

public class MappingStrategy {
private final List>> strategy;
private boolean allSet;

public MappingStrategy()
{
this.strategy = new ArrayList<>();
this.allSet = false;
}

public void addColumn(int offset, FailableBiConsumer setter)
{
this.strategy.add(Pair.of(offset, setter));
}

public void finish(int num_fields)
{
// The list should already be in the correct order because Criteria 
loops through the columns
// in the same order in which they are added to the SQL statement but 
just in case something weird
// is being done this gets us closer to the desired contract of 
ResultSet of looping over monotonically
// increasing indices of columns only.
this.strategy.sort(Comparator.comparing(Pair::getLeft));
this.allSet = this.strategy.size() == num_fields;
}

public boolean isEmpty()
{
return this.strategy.isEmpty();
}

public boolean isAllSet() {
return this.allSet;
}

public void execute(ResultSet result, T instance) throws TorqueException
{
for (Pair> 
strategy : this.strategy)
{
strategy.getRight().accept(result, instance);
}
}
}
{code}
This code adds a single MappingStrategy class which holds a list of lambdas 
which know how to best query a ResultSet to construct a T from it as well as 
the necessary code for a RecordMapper to utilize this MappingStrategy to speed 
up object construction significantly!
However, the actual strategy object is obviously tied to a given 
Criterias/Queries selected columns and thus can't be kept by the 
RecordMapperXXX objects themselves. (This would lead to exceptions with multple 
threads doing queries and would require extensive cache invalidation checks for 
all processRow invokations to create a new 

[jira] [Comment Edited] (TORQUE-364) RecordMapper very slow on many columns in table

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt edited comment on TORQUE-364 at 4/20/24 10:23 PM:
-

To point 3. we finally got a slightly nicer working prototype to share;
{code:java}
### recordMapperBase.vm
---+
// at the top import the new runtime MappingStrategy class
import org.apache.torque.om.mapper.MappingStrategy;
---
---+
// Should this be cached per RecordMapper (Thread safety/Multi query safety?)
private MappingStrategy<${dbObjectClassName}> strategy;

// A sample prepareStrategy implementation, still missing the new HashSet 
optimization!
public MappingStrategy<${dbObjectClassName}> prepareStrategy(Criteria criteria, 
int offset)
{
MappingStrategy<${dbObjectClassName}> strategy = new 
MappingStrategy<${dbObjectClassName}>();
if (criteria == null)
{
return strategy;
}

int nextOuterOffset = offset + 1;
List selectColumns = criteria.getSelectColumns();
List columnsWithoutOffset = selectColumns.subList(
offset,
selectColumns.size());

for (Column column : columnsWithoutOffset)
{
// Create a final local copy for this iteration to be passed into the 
lambdas
final int nextOffset = nextOuterOffset;
String columnExpression = column.getSqlExpression();
#set ( $else = "" )
#foreach ($columnElement in $torqueGen.getChildren("column"))
#set ( $setter = $columnElement.getAttribute("setter") )
#set ( $getter = $columnElement.getAttribute("getter") )
#set ( $peerColumnName = $columnElement.getAttribute("peerColumnName") )
#set ( $fieldType = $columnElement.getAttribute("fieldType") )
${else}if (${peerColumnName}_EXPRESSION.equals(columnExpression))
{
strategy.addColumn(nextOffset, (res, inst) -> 
inst.${setter}(this.${getter}(res, nextOffset)));
}
#set ( $else = "else ")
#end
nextOuterOffset += 1;
}
strategy.finish($torqueGen.getChildren("column").size());
return strategy;
}
---
---+
// in processRow()
// this could theoretically replace BOTh if cases (criteria == null AND != 
null)
// However criteria == null might still be slightly faster than this!

// Wherever the MappingStrategy is ultimately stored should probably handle 
invalidation
// Storing it in Criteria for example would allow invalidating whenever a 
select columns is added/modified
//  However, for testing purposes we just placed it directly in processRow 
to show viability.
if (this.strategy == null) {
this.strategy = prepareStrategy(criteria, offset);
}
this.strategy.execute(resultSet, $field);
---


### MappingStrategy.java

package org.apache.torque.om.mapper;

import org.apache.commons.lang3.tuple.Pair;
import org.apache.commons.lang3.function.FailableBiConsumer;
import org.apache.torque.TorqueException;

import java.sql.ResultSet;
import java.util.ArrayList;
import java.util.Comparator;
import java.util.List;

public class MappingStrategy {
private final List>> strategy;
private boolean allSet;

public MappingStrategy()
{
this.strategy = new ArrayList<>();
this.allSet = false;
}

public void addColumn(int offset, FailableBiConsumer setter)
{
this.strategy.add(Pair.of(offset, setter));
}

public void finish(int num_fields)
{
// The list should already be in the correct order because Criteria 
loops through the columns
// in the same order in which they are added to the SQL statement but 
just in case something weird
// is being done this gets us closer to the desired contract of 
ResultSet of looping over monotonically
// increasing indices of columns only.
this.strategy.sort(Comparator.comparing(Pair::getLeft));
this.allSet = this.strategy.size() == num_fields;
}

public boolean isEmpty()
{
return this.strategy.isEmpty();
}

public boolean isAllSet() {
return this.allSet;
}

public void execute(ResultSet result, T instance) throws TorqueException
{
for (Pair> 
strategy : this.strategy)
{
strategy.getRight().accept(result, instance);
}
}
}
{code}
This code adds a single MappingStrategy class which holds a list of lambdas 
which know how to best query a ResultSet to construct a T from it as well as 
the necessary code for a RecordMapper to utilize this MappingStrategy to speed 
up object construction significantly!
However, the actual strategy object is obviously tied to a given 
Criterias/Queries selected columns and thus can't be kept by the 
RecordMapperXXX objects themselves. (This would lead to exceptions with multple 
threads doing queries and would require extensive cache invalidation chec

[jira] [Commented] (TORQUE-364) RecordMapper very slow on many columns in table

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt commented on TORQUE-364:
---

Regarding point 1:
Our solution with the {{criteria.getSelectColumns().size()}} check only works 
if the BaseRecordMapper is used *and* never used by any other custom record 
mappers to "chain load". i.e. If I were to implement a FooAndBarMapper which 
selects 2 of 5 columns from a table Foo and 3 of 3 columns from a table Bar and 
then just call into the FooRecordMapper and BarRecordMapper with appropriate 
offsets the check would break and I would get a corrupted Foo object with 
garbage data or an exception for storing/reading invalid types from the 
ResultSet.

Regarding point 2: The following code should do the thing inside 
{{org/apache/torque/templates/om/templates/recordmapper/base/recordMapperBase.vm}}
{code:java}
## Cached SQL expressions to speed up looking for columns selected by a given 
Criteria
#foreach ($columnElement in $torqueGen.getChildren("column"))
#set ( $peerColumnName = $columnElement.getAttribute("peerColumnName") )
private static final String ${peerColumnName}_EXPRESSION = 
${basePeerClassName}.${peerColumnName}.getSqlExpression();
#end
{code}
As well as
{code:java}
String columnExpression = column.getSqlExpression();
// snip...
${else}if (${peerColumnName}_EXPRESSION.equals(columnExpression))
{code}
In the for each loop over columns

We are currently investigating on point 3 and will provide further information 
soon.

As for point 4, improvements are always nice to see.

Regards [~mwriedt] and [~refarb] (<- whose account seems to be missing?)

> RecordMapper very slow on many columns in table
> ---
>
> Key: TORQUE-364
> URL: https://issues.apache.org/jira/browse/TORQUE-364
> Project: Torque
>  Issue Type: Improvement
>  Components: Runtime, Templates
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: criteria_api, om, performance, recordmapper, templates
>
> When "doSelect()" a large quantity of columns in a table the default 
> RecordMappers generated by Om-Templates (processRow()) cause an  
> !https://wikimedia.org/api/rest_v1/media/math/render/svg/4441d9689c0e6b2c47994e2f587ac5378faeefba!
>  Problem. (technically O(rows * columns))
> Specifically, constantly generating the SQL expression of all possible 
> columns for every row in the result causes excessive use of StringBuilders 
> which slow the mapping process to a crawl.
> I currently have two ideas on how best to tackle this problem:
>  # Either generate all SQL column expressions once when a (template 
> generated) RecordMapper is first created (using final static String fields) 
> thus reducing the cost for every row to generating all selected column SQL 
> expressions  once(instead of every selected column times every available 
> column)
>  # Or (in case the first approach generates unacceptably excessive number of 
> fields for RecordMappers) adjust the RecordMapper API to allow a 
> "prepare(Criteria, int offset)" method to be called once before processing 
> any rows and implement it on generated RecordMappers to scan the Criteria and 
> build two lists: One containing references to the setXXX methods of the 
> mapper in the order they appear in the ResultSet (via the order in the 
> Criteria) and a second list containing the corresponding column offsets. This 
> would allow the processRow method to only iterated over both lists 
> simultaneously and call the referenced methods with the result set and offset 
> immediately. (Alternatively one list using lambdas could be used but I am 
> currently not sure about the stance or impact of these lambdas in the Torque 
> project.)
> credits to [~refarb] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (TORQUE-364) RecordMapper very slow on many columns in table

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt commented on TORQUE-364:
---

I'm currently trying to work myself into this issue again, as this was quite a 
while ago.
At that time I was upgrading an old Torque-based project from version 3 to 
version 5.

The issue manifested everytime we tried to get every column instead of defining 
specific columns to show.
Our project has pretty large number of columns (over 200 at some times). 
With debugging turned on, we observed a large number of StringBuilder calls to 
create the select statement.

The BaseXXXRecordMapper function {{processRow()}} seems to be always called 
with {{{}criteria != null{}}}, even when doing a simple {{doSelect()}}
This results in mapping every column instead of directly using the getters.

Our workaround was to extend the if-else in {{{}processRow(){}}}:
{{if (criteria == null || criteria.getSelectColumns().size() - offset == 
BaseXXXPeer.numColumns)}}

We also added static Strings for every Expression, but I don't remember 
exactly, if this improved speed or something.

{{private static final String IDExpression;}}
{{static {}}
{{IDExpression = BaseXXXPeer.ID.getSqlExpression();}}
}

I will take a more detailed look into this with ~refarb in the near future. 

> RecordMapper very slow on many columns in table
> ---
>
> Key: TORQUE-364
> URL: https://issues.apache.org/jira/browse/TORQUE-364
> Project: Torque
>  Issue Type: Improvement
>  Components: Runtime, Templates
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: criteria_api, om, performance, recordmapper, templates
>
> When "doSelect()" a large quantity of columns in a table the default 
> RecordMappers generated by Om-Templates (processRow()) cause an  
> !https://wikimedia.org/api/rest_v1/media/math/render/svg/4441d9689c0e6b2c47994e2f587ac5378faeefba!
>  Problem. (technically O(rows * columns))
> Specifically, constantly generating the SQL expression of all possible 
> columns for every row in the result causes excessive use of StringBuilders 
> which slow the mapping process to a crawl.
> I currently have two ideas on how best to tackle this problem:
>  # Either generate all SQL column expressions once when a (template 
> generated) RecordMapper is first created (using final static String fields) 
> thus reducing the cost for every row to generating all selected column SQL 
> expressions  once(instead of every selected column times every available 
> column)
>  # Or (in case the first approach generates unacceptably excessive number of 
> fields for RecordMappers) adjust the RecordMapper API to allow a 
> "prepare(Criteria, int offset)" method to be called once before processing 
> any rows and implement it on generated RecordMappers to scan the Criteria and 
> build two lists: One containing references to the setXXX methods of the 
> mapper in the order they appear in the ResultSet (via the order in the 
> Criteria) and a second list containing the corresponding column offsets. This 
> would allow the processRow method to only iterated over both lists 
> simultaneously and call the referenced methods with the result set and offset 
> immediately. (Alternatively one list using lambdas could be used but I am 
> currently not sure about the stance or impact of these lambdas in the Torque 
> project.)
> credits to [~refarb] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Resolved] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt resolved TORQUE-361.
---
Resolution: Fixed

Fixed in svn by [~gk]

> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: groovy
> Fix For: 5.2
>
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve class 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Resolved] (TORQUE-363) Criterion handles "IS NULL" incorrectly

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt resolved TORQUE-363.
---
Fix Version/s: 5.2
   Resolution: Fixed

Fixed in svn

> Criterion handles "IS NULL" incorrectly
> ---
>
> Key: TORQUE-363
> URL: https://issues.apache.org/jira/browse/TORQUE-363
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Assignee: Max Philipp Wriedt
>Priority: Major
>  Labels: criteria_api, criterion
> Fix For: 5.2
>
>
> When using Criterion and want to use ISNULL (and maybe also applicable to 
> ISNOTNULL)
> {code:java}
> Criterion criterion1 = new Criterion(ID, Criteria.ISNULL); {code}
> The generated Code adds an equal-sign (=). In a Criteria this is not the case.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-363) Criterion handles "IS NULL" incorrectly

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-363:
--
Priority: Major  (was: Critical)

> Criterion handles "IS NULL" incorrectly
> ---
>
> Key: TORQUE-363
> URL: https://issues.apache.org/jira/browse/TORQUE-363
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Assignee: Max Philipp Wriedt
>Priority: Major
>  Labels: criteria_api, criterion
>
> When using Criterion and want to use ISNULL (and maybe also applicable to 
> ISNOTNULL)
> {code:java}
> Criterion criterion1 = new Criterion(ID, Criteria.ISNULL); {code}
> The generated Code adds an equal-sign (=). In a Criteria this is not the case.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-364) RecordMapper very slow on many columns in table

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-364:
--
Description: 
When "doSelect()" a large quantity of columns in a table the default 
RecordMappers generated by Om-Templates (processRow()) cause an  
!https://wikimedia.org/api/rest_v1/media/math/render/svg/4441d9689c0e6b2c47994e2f587ac5378faeefba!
 Problem. (technically O(rows * columns))

Specifically, constantly generating the SQL expression of all possible columns 
for every row in the result causes excessive use of StringBuilders which slow 
the mapping process to a crawl.

I currently have two ideas on how best to tackle this problem:
 # Either generate all SQL column expressions once when a (template generated) 
RecordMapper is first created (using final static String fields) thus reducing 
the cost for every row to generating all selected column SQL expressions  
once(instead of every selected column times every available column)
 # Or (in case the first approach generates unacceptably excessive number of 
fields for RecordMappers) adjust the RecordMapper API to allow a 
"prepare(Criteria, int offset)" method to be called once before processing any 
rows and implement it on generated RecordMappers to scan the Criteria and build 
two lists: One containing references to the setXXX methods of the mapper in the 
order they appear in the ResultSet (via the order in the Criteria) and a second 
list containing the corresponding column offsets. This would allow the 
processRow method to only iterated over both lists simultaneously and call the 
referenced methods with the result set and offset immediately. (Alternatively 
one list using lambdas could be used but I am currently not sure about the 
stance or impact of these lambdas in the Torque project.)

credits to [~refarb] 

  was:
When "doSelect()" a large quantity of columns in a table the default 
RecordMappers generated by Om-Templates (processRow()) cause an  
!https://wikimedia.org/api/rest_v1/media/math/render/svg/4441d9689c0e6b2c47994e2f587ac5378faeefba!
 Problem. (technically O(rows * columns))



Specifically, constantly generating the SQL expression of all possible columns 
for every row in the result causes excessive use of StringBuilders which slow 
the mapping process to a crawl.

I currently have two ideas on how best to tackle this problem:
 # Either generate all SQL column expressions once when a (template generated) 
RecordMapper is first created (using final static String fields) thus reducing 
the cost for every row to generating all selected column SQL expressions  
once(instead of every selected column times every available column)
 # Or (in case the first approach generates unacceptably excessive number of 
fields for RecordMappers) adjust the RecordMapper API to allow a 
"prepare(Criteria, int offset)" method to be called once before processing any 
rows and implement it on generated RecordMappers to scan the Criteria and build 
two lists: One containing references to the setXXX methods of the mapper in the 
order they appear in the ResultSet (via the order in the Criteria) and a second 
list containing the corresponding column offsets. This would allow the 
processRow method to only iterated over both lists simultaneously and call the 
referenced methods with the result set and offset immediately. (Alternatively 
one list using lambdas could be used but I am currently not sure about the 
stance or impact of these lambdas in the Torque project.)


> RecordMapper very slow on many columns in table
> ---
>
> Key: TORQUE-364
> URL: https://issues.apache.org/jira/browse/TORQUE-364
> Project: Torque
>  Issue Type: Improvement
>  Components: Runtime, Templates
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: criteria_api, om, performance, recordmapper, templates
>
> When "doSelect()" a large quantity of columns in a table the default 
> RecordMappers generated by Om-Templates (processRow()) cause an  
> !https://wikimedia.org/api/rest_v1/media/math/render/svg/4441d9689c0e6b2c47994e2f587ac5378faeefba!
>  Problem. (technically O(rows * columns))
> Specifically, constantly generating the SQL expression of all possible 
> columns for every row in the result causes excessive use of StringBuilders 
> which slow the mapping process to a crawl.
> I currently have two ideas on how best to tackle this problem:
>  # Either generate all SQL column expressions once when a (template 
> generated) RecordMapper is first created (using final static String fields) 
> thus reducing the cost for every row to generating all selected column SQL 
> expressions  once(instead of every selected column times every available 
> column)
>  # Or (in case the first approach generates una

[jira] [Updated] (TORQUE-366) JavaDocs search not working

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-366:
--
Labels: javadocs  (was: )

> JavaDocs search not working
> ---
>
> Key: TORQUE-366
> URL: https://issues.apache.org/jira/browse/TORQUE-366
> Project: Torque
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: javadocs
>
> When using the JavaDocs the QuickSearch works, but is referring to wrong link
> e.g.: searching for CountHelper resulting in
> {code:java}
> https://db.apache.org/torque/torque-5.1/documentation/modules/runtime/reports/apidocs/undefined/org/apache/torque/util/CountHelper.html{code}
> rather than
> {code:java}
> https://db.apache.org/torque/torque-5.1/documentation/modules/runtime/reports/apidocs/org/apache/torque/util/CountHelper.html{code}
> Also the JavaDocs show "SNAPSHOT-5.2", why isn't it fixed to 5.1 as it is the 
> latest release?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Created] (TORQUE-366) JavaDocs search not working

[Max Philipp Wriedt (Jira)]

Max Philipp Wriedt created TORQUE-366:
-

 Summary: JavaDocs search not working
 Key: TORQUE-366
 URL: https://issues.apache.org/jira/browse/TORQUE-366
 Project: Torque
  Issue Type: Improvement
  Components: Documentation
Reporter: Max Philipp Wriedt


When using the JavaDocs the QuickSearch works, but is referring to wrong link

e.g.: searching for CountHelper resulting in
{code:java}
https://db.apache.org/torque/torque-5.1/documentation/modules/runtime/reports/apidocs/undefined/org/apache/torque/util/CountHelper.html{code}
rather than
{code:java}
https://db.apache.org/torque/torque-5.1/documentation/modules/runtime/reports/apidocs/org/apache/torque/util/CountHelper.html{code}
Also the JavaDocs show "SNAPSHOT-5.2", why isn't it fixed to 5.1 as it is the 
latest release?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-365) CountHelper doesn't work, when Criteria has "setDisctint()"

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-365:
--
Description: 
When passing a Criteria which has been modified with "setDistinct()" the 
CountHelper creates a wrong SQL-Statement containing "SELECT COUNT(DISTINCT 
*)". This is not valid SQL.

A common workaround is to set a column to count while creating the CountHelper.

If I am not wrong we could also solve this problem inside the count()-function 
of the CountHelper itself, as there is already a handler for DISTINCT cases.
{code:java}
boolean distinct = isAndSetDistinct(criteriaSelectModifiers) && 
!Objects.equals(columnName, "*"); // 
org.apache.torque.utils.CountHelper:202{code}
This could probably set "DISTINCT" directly behind the SELECT, but not inside 
the "COUNT()" clause, generating at least valid SQL.

  was:
When passing a Criteria which has been modified with "setDistinct()" the 
CountHelper creates a wrong SQL-Statement containing "SELECT COUNT(DISTINCT 
*)". This is not valid SQL.

A common workaround is to set a column to count while creating the CountHelper.

If I am not wrong we could also solve this problem inside the count()-function 
of the CountHelper itself, as there is already a handler for DISTINCT cases.
{code:java}
boolean distinct = isAndSetDistinct(criteriaSelectModifiers) && 
!Objects.equals(columnName, "*");{code}
This could probably set "DISTINCT" directly behind the SELECT, but not inside 
the "COUNT()" clause, generating at least valid SQL.


> CountHelper doesn't work, when Criteria has "setDisctint()"
> ---
>
> Key: TORQUE-365
> URL: https://issues.apache.org/jira/browse/TORQUE-365
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Minor
>  Labels: CountHelper, distinct
>
> When passing a Criteria which has been modified with "setDistinct()" the 
> CountHelper creates a wrong SQL-Statement containing "SELECT COUNT(DISTINCT 
> *)". This is not valid SQL.
> A common workaround is to set a column to count while creating the 
> CountHelper.
> If I am not wrong we could also solve this problem inside the 
> count()-function of the CountHelper itself, as there is already a handler for 
> DISTINCT cases.
> {code:java}
> boolean distinct = isAndSetDistinct(criteriaSelectModifiers) && 
> !Objects.equals(columnName, "*"); // 
> org.apache.torque.utils.CountHelper:202{code}
> This could probably set "DISTINCT" directly behind the SELECT, but not inside 
> the "COUNT()" clause, generating at least valid SQL.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-365) CountHelper doesn't work, when Criteria has "setDisctint()"

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-365:
--
Labels: CountHelper distinct  (was: )

> CountHelper doesn't work, when Criteria has "setDisctint()"
> ---
>
> Key: TORQUE-365
> URL: https://issues.apache.org/jira/browse/TORQUE-365
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Minor
>  Labels: CountHelper, distinct
>
> When passing a Criteria which has been modified with "setDistinct()" the 
> CountHelper creates a wrong SQL-Statement containing "SELECT COUNT(DISTINCT 
> *)". This is not valid SQL.
> A common workaround is to set a column to count while creating the 
> CountHelper.
> If I am not wrong we could also solve this problem inside the 
> count()-function of the CountHelper itself, as there is already a handler for 
> DISTINCT cases.
> {code:java}
> boolean distinct = isAndSetDistinct(criteriaSelectModifiers) && 
> !Objects.equals(columnName, "*");{code}
> This could probably set "DISTINCT" directly behind the SELECT, but not inside 
> the "COUNT()" clause, generating at least valid SQL.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Created] (TORQUE-365) CountHelper doesn't work, when Criteria has "setDisctint()"

[Max Philipp Wriedt (Jira)]

Max Philipp Wriedt created TORQUE-365:
-

 Summary: CountHelper doesn't work, when Criteria has 
"setDisctint()"
 Key: TORQUE-365
 URL: https://issues.apache.org/jira/browse/TORQUE-365
 Project: Torque
  Issue Type: Bug
  Components: Runtime
Affects Versions: 5.1
Reporter: Max Philipp Wriedt


When passing a Criteria which has been modified with "setDistinct()" the 
CountHelper creates a wrong SQL-Statement containing "SELECT COUNT(DISTINCT 
*)". This is not valid SQL.

A common workaround is to set a column to count while creating the CountHelper.

If I am not wrong we could also solve this problem inside the count()-function 
of the CountHelper itself, as there is already a handler for DISTINCT cases.
{code:java}
boolean distinct = isAndSetDistinct(criteriaSelectModifiers) && 
!Objects.equals(columnName, "*");{code}
This could probably set "DISTINCT" directly behind the SELECT, but not inside 
the "COUNT()" clause, generating at least valid SQL.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-364) RecordMapper very slow on many columns in table

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-364:
--
Labels: criteria_api om performance recordmapper templates  (was: )

> RecordMapper very slow on many columns in table
> ---
>
> Key: TORQUE-364
> URL: https://issues.apache.org/jira/browse/TORQUE-364
> Project: Torque
>  Issue Type: Improvement
>  Components: Runtime, Templates
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: criteria_api, om, performance, recordmapper, templates
>
> When "doSelect()" a large quantity of columns in a table the default 
> RecordMappers generated by Om-Templates (processRow()) cause an  
> !https://wikimedia.org/api/rest_v1/media/math/render/svg/4441d9689c0e6b2c47994e2f587ac5378faeefba!
>  Problem. (technically O(rows * columns))
> Specifically, constantly generating the SQL expression of all possible 
> columns for every row in the result causes excessive use of StringBuilders 
> which slow the mapping process to a crawl.
> I currently have two ideas on how best to tackle this problem:
>  # Either generate all SQL column expressions once when a (template 
> generated) RecordMapper is first created (using final static String fields) 
> thus reducing the cost for every row to generating all selected column SQL 
> expressions  once(instead of every selected column times every available 
> column)
>  # Or (in case the first approach generates unacceptably excessive number of 
> fields for RecordMappers) adjust the RecordMapper API to allow a 
> "prepare(Criteria, int offset)" method to be called once before processing 
> any rows and implement it on generated RecordMappers to scan the Criteria and 
> build two lists: One containing references to the setXXX methods of the 
> mapper in the order they appear in the ResultSet (via the order in the 
> Criteria) and a second list containing the corresponding column offsets. This 
> would allow the processRow method to only iterated over both lists 
> simultaneously and call the referenced methods with the result set and offset 
> immediately. (Alternatively one list using lambdas could be used but I am 
> currently not sure about the stance or impact of these lambdas in the Torque 
> project.)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Created] (TORQUE-364) RecordMapper very slow on many columns in table

[Max Philipp Wriedt (Jira)]

Max Philipp Wriedt created TORQUE-364:
-

 Summary: RecordMapper very slow on many columns in table
 Key: TORQUE-364
 URL: https://issues.apache.org/jira/browse/TORQUE-364
 Project: Torque
  Issue Type: Improvement
  Components: Runtime, Templates
Affects Versions: 5.1
Reporter: Max Philipp Wriedt


When "doSelect()" a large quantity of columns in a table the default 
RecordMappers generated by Om-Templates (processRow()) cause an  
!https://wikimedia.org/api/rest_v1/media/math/render/svg/4441d9689c0e6b2c47994e2f587ac5378faeefba!
 Problem. (technically O(rows * columns))



Specifically, constantly generating the SQL expression of all possible columns 
for every row in the result causes excessive use of StringBuilders which slow 
the mapping process to a crawl.

I currently have two ideas on how best to tackle this problem:
 # Either generate all SQL column expressions once when a (template generated) 
RecordMapper is first created (using final static String fields) thus reducing 
the cost for every row to generating all selected column SQL expressions  
once(instead of every selected column times every available column)
 # Or (in case the first approach generates unacceptably excessive number of 
fields for RecordMappers) adjust the RecordMapper API to allow a 
"prepare(Criteria, int offset)" method to be called once before processing any 
rows and implement it on generated RecordMappers to scan the Criteria and build 
two lists: One containing references to the setXXX methods of the mapper in the 
order they appear in the ResultSet (via the order in the Criteria) and a second 
list containing the corresponding column offsets. This would allow the 
processRow method to only iterated over both lists simultaneously and call the 
referenced methods with the result set and offset immediately. (Alternatively 
one list using lambdas could be used but I am currently not sure about the 
stance or impact of these lambdas in the Torque project.)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Assigned] (TORQUE-363) Criterion handles "IS NULL" incorrectly

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt reassigned TORQUE-363:
-

Assignee: Max Philipp Wriedt

> Criterion handles "IS NULL" incorrectly
> ---
>
> Key: TORQUE-363
> URL: https://issues.apache.org/jira/browse/TORQUE-363
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Assignee: Max Philipp Wriedt
>Priority: Critical
>  Labels: criteria_api, criterion
>
> When using Criterion and want to use ISNULL (and maybe also applicable to 
> ISNOTNULL)
> {code:java}
> Criterion criterion1 = new Criterion(ID, Criteria.ISNULL); {code}
> The generated Code adds an equal-sign (=). In a Criteria this is not the case.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (TORQUE-363) Criterion handles "IS NULL" incorrectly

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt commented on TORQUE-363:
---

We could handle a Criterion constructed with SqlEnum as second value:

 
{code:java}
public Criterion(final Object lValue, final SqlEnum sqlEnum)
{
this(lValue, null, sqlEnum, null, null);
} {code}
or do I overlook something?

 

> Criterion handles "IS NULL" incorrectly
> ---
>
> Key: TORQUE-363
> URL: https://issues.apache.org/jira/browse/TORQUE-363
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Critical
>  Labels: criteria_api, criterion
>
> When using Criterion and want to use ISNULL (and maybe also applicable to 
> ISNOTNULL)
> {code:java}
> Criterion criterion1 = new Criterion(ID, Criteria.ISNULL); {code}
> The generated Code adds an equal-sign (=). In a Criteria this is not the case.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-361:
--
Fix Version/s: 5.2

> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: groovy
> Fix For: 5.2
>
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve class 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt commented on TORQUE-361:
---

I have just realized, that you put that code inside the subversion.
I finally got to test it and can confirm it works fine in my use case.
 
the gradle plugin is still in development and requires some refactoring 
regarding the configuration, so I consider it "early alpha".
I will continue working on it soon.

> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: groovy
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve class 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-362) SharedPool2DataSourceFactory says property is not supported

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-362:
--
Affects Version/s: 5.0

> SharedPool2DataSourceFactory says property is not supported
> ---
>
> Key: TORQUE-362
> URL: https://issues.apache.org/jira/browse/TORQUE-362
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: SharedPool2DataSourceFactory
>
> When I set properties like:
> {code:java}
> torque.dsfactory.test.pool.maxTotal = 20
> torque.dsfactory.test.pool.maxIdle = 15
> torque.dsfactory.test.pool.maxWaitMillis = 1
> torque.dsfactory.test.pool.timeBetweenEvictionRunsMillis = 30
> torque.dsfactory.test.pool.minEvictableIdleTimeMillis = 360
> // rest of config for reference
> torque.database.default = test
> torque.dsfactory.hvp.factory = 
> org.apache.torque.dsfactory.SharedPool2DataSourceFactory
> torque.database.hvp.adapter = mysql
> torque.dsfactory.test.connection.driver = org.mariadb.jdbc.Driver
> torque.dsfactory.test.connection.url = jdbc:mariadb://localhost:3306/test
> torque.dsfactory.test.connection.user = user
> torque.dsfactory.test.connection.password = password{code}
> the initialization throws:
>  
> {code:java}
> 12:33:09.565 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: maxIdle  
> value: 15  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.570 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> maxWaitMillis  value: 1  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.570 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> timeBetweenEvictionRunsMillis  value: 30  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.571 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> minEvictableIdleTimeMillis  value: 360  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource {code}
>  
> The reference says those properties exist: 
> [https://commons.apache.org/proper/commons-dbcp/configuration.html]
>  
> Am I missing something here? As you can see, I use the MariaDB JDBC Driver, 
> but I don't think this has effects to the pool properties?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-363) Criterion handles "IS NULL" incorrectly

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-363:
--
Labels: criteria_api criterion  (was: )

> Criterion handles "IS NULL" incorrectly
> ---
>
> Key: TORQUE-363
> URL: https://issues.apache.org/jira/browse/TORQUE-363
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Critical
>  Labels: criteria_api, criterion
>
> When using Criterion and want to use ISNULL (and maybe also applicable to 
> ISNOTNULL)
> {code:java}
> Criterion criterion1 = new Criterion(ID, Criteria.ISNULL); {code}
> The generated Code adds an equal-sign (=). In a Criteria this is not the case.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-362) SharedPool2DataSourceFactory says property is not supported

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-362:
--
Priority: Major  (was: Minor)

> SharedPool2DataSourceFactory says property is not supported
> ---
>
> Key: TORQUE-362
> URL: https://issues.apache.org/jira/browse/TORQUE-362
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: SharedPool2DataSourceFactory
>
> When I set properties like:
> {code:java}
> torque.dsfactory.test.pool.maxTotal = 20
> torque.dsfactory.test.pool.maxIdle = 15
> torque.dsfactory.test.pool.maxWaitMillis = 1
> torque.dsfactory.test.pool.timeBetweenEvictionRunsMillis = 30
> torque.dsfactory.test.pool.minEvictableIdleTimeMillis = 360
> // rest of config for reference
> torque.database.default = test
> torque.dsfactory.hvp.factory = 
> org.apache.torque.dsfactory.SharedPool2DataSourceFactory
> torque.database.hvp.adapter = mysql
> torque.dsfactory.test.connection.driver = org.mariadb.jdbc.Driver
> torque.dsfactory.test.connection.url = jdbc:mariadb://localhost:3306/test
> torque.dsfactory.test.connection.user = user
> torque.dsfactory.test.connection.password = password{code}
> the initialization throws:
>  
> {code:java}
> 12:33:09.565 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: maxIdle  
> value: 15  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.570 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> maxWaitMillis  value: 1  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.570 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> timeBetweenEvictionRunsMillis  value: 30  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.571 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> minEvictableIdleTimeMillis  value: 360  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource {code}
>  
> The reference says those properties exist: 
> [https://commons.apache.org/proper/commons-dbcp/configuration.html]
>  
> Am I missing something here? As you can see, I use the MariaDB JDBC Driver, 
> but I don't think this has effects to the pool properties?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-363) Criterion handles "IS NULL" incorrectly

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-363:
--
Description: 
When using Criterion and want to use ISNULL (and maybe also applicable to 
ISNOTNULL)
{code:java}
Criterion criterion1 = new Criterion(ID, Criteria.ISNULL); {code}
The generated Code adds an equal-sign (=). In a Criteria this is not the case.

  was:
When using Criterion and want to use the ISNULL 
{code:java}
Criterion criterion1 = new Criterion(ID, Criteria.ISNULL); {code}


> Criterion handles "IS NULL" incorrectly
> ---
>
> Key: TORQUE-363
> URL: https://issues.apache.org/jira/browse/TORQUE-363
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Critical
>
> When using Criterion and want to use ISNULL (and maybe also applicable to 
> ISNOTNULL)
> {code:java}
> Criterion criterion1 = new Criterion(ID, Criteria.ISNULL); {code}
> The generated Code adds an equal-sign (=). In a Criteria this is not the case.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-363) Criterion handles "IS NULL" incorrectly

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-363:
--
Description: 
When using Criterion and want to use the ISNULL 
{code:java}
Criterion criterion1 = new Criterion(ID, Criteria.ISNULL); {code}

> Criterion handles "IS NULL" incorrectly
> ---
>
> Key: TORQUE-363
> URL: https://issues.apache.org/jira/browse/TORQUE-363
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Critical
>
> When using Criterion and want to use the ISNULL 
> {code:java}
> Criterion criterion1 = new Criterion(ID, Criteria.ISNULL); {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-363) Criterion handles "IS NULL" incorrectly

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-363:
--
Component/s: Runtime

> Criterion handles "IS NULL" incorrectly
> ---
>
> Key: TORQUE-363
> URL: https://issues.apache.org/jira/browse/TORQUE-363
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Critical
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-363) Criterion handles "IS NULL" incorrectly

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-363:
--
Affects Version/s: 5.1
   5.0

> Criterion handles "IS NULL" incorrectly
> ---
>
> Key: TORQUE-363
> URL: https://issues.apache.org/jira/browse/TORQUE-363
> Project: Torque
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Critical
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Created] (TORQUE-363) Criterion handles "IS NULL" incorrectly

[Max Philipp Wriedt (Jira)]

Max Philipp Wriedt created TORQUE-363:
-

 Summary: Criterion handles "IS NULL" incorrectly
 Key: TORQUE-363
 URL: https://issues.apache.org/jira/browse/TORQUE-363
 Project: Torque
  Issue Type: Bug
Reporter: Max Philipp Wriedt






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-363) Criterion handles "IS NULL" incorrectly

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-363:
--
Priority: Critical  (was: Major)

> Criterion handles "IS NULL" incorrectly
> ---
>
> Key: TORQUE-363
> URL: https://issues.apache.org/jira/browse/TORQUE-363
> Project: Torque
>  Issue Type: Bug
>Reporter: Max Philipp Wriedt
>Priority: Critical
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-362) SharedPool2DataSourceFactory says property is not supported

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-362:
--
Description: 
When I set properties like:
{code:java}
torque.dsfactory.test.pool.maxTotal = 20
torque.dsfactory.test.pool.maxIdle = 15
torque.dsfactory.test.pool.maxWaitMillis = 1
torque.dsfactory.test.pool.timeBetweenEvictionRunsMillis = 30
torque.dsfactory.test.pool.minEvictableIdleTimeMillis = 360
// rest of config for reference
torque.database.default = test
torque.dsfactory.hvp.factory = 
org.apache.torque.dsfactory.SharedPool2DataSourceFactory
torque.database.hvp.adapter = mysql
torque.dsfactory.test.connection.driver = org.mariadb.jdbc.Driver
torque.dsfactory.test.connection.url = jdbc:mariadb://localhost:3306/test
torque.dsfactory.test.connection.user = user
torque.dsfactory.test.connection.password = password{code}
the initialization throws:

 
{code:java}
12:33:09.565 [main] ERROR org.apache.torque.dsfactory.AbstractDataSourceFactory 
- Property: maxIdle  value: 15  is not supported by DataSource: 
org.apache.commons.dbcp2.datasources.SharedPoolDataSource
12:33:09.570 [main] ERROR org.apache.torque.dsfactory.AbstractDataSourceFactory 
- Property: maxWaitMillis  value: 1  is not supported by DataSource: 
org.apache.commons.dbcp2.datasources.SharedPoolDataSource
12:33:09.570 [main] ERROR org.apache.torque.dsfactory.AbstractDataSourceFactory 
- Property: timeBetweenEvictionRunsMillis  value: 30  is not supported by 
DataSource: org.apache.commons.dbcp2.datasources.SharedPoolDataSource
12:33:09.571 [main] ERROR org.apache.torque.dsfactory.AbstractDataSourceFactory 
- Property: minEvictableIdleTimeMillis  value: 360  is not supported by 
DataSource: org.apache.commons.dbcp2.datasources.SharedPoolDataSource {code}
 
The reference says those properties exist: 
[https://commons.apache.org/proper/commons-dbcp/configuration.html]
 
Am I missing something here? As you can see, I use the MariaDB JDBC Driver, but 
I don't think this has effects to the pool properties?

  was:
When I set properties like:
{code:java}
torque.dsfactory.test.pool.maxTotal = 20
torque.dsfactory.test.pool.maxIdle = 15
torque.dsfactory.test.pool.maxWaitMillis = 1
torque.dsfactory.test.pool.timeBetweenEvictionRunsMillis = 30
torque.dsfactory.test.pool.minEvictableIdleTimeMillis = 360
// rest of config for reference
torque.database.default = test
torque.dsfactory.hvp.factory = 
org.apache.torque.dsfactory.SharedPool2DataSourceFactory
torque.database.hvp.adapter = mysql
torque.dsfactory.test.connection.driver = org.mariadb.jdbc.Driver
torque.dsfactory.test.connection.url = jdbc:mariadb://localhost:3306/hvp
torque.dsfactory.test.connection.user = user
torque.dsfactory.test.connection.password = password{code}
the initialization throws:

 
{code:java}
12:33:09.565 [main] ERROR org.apache.torque.dsfactory.AbstractDataSourceFactory 
- Property: maxIdle  value: 15  is not supported by DataSource: 
org.apache.commons.dbcp2.datasources.SharedPoolDataSource
12:33:09.570 [main] ERROR org.apache.torque.dsfactory.AbstractDataSourceFactory 
- Property: maxWaitMillis  value: 1  is not supported by DataSource: 
org.apache.commons.dbcp2.datasources.SharedPoolDataSource
12:33:09.570 [main] ERROR org.apache.torque.dsfactory.AbstractDataSourceFactory 
- Property: timeBetweenEvictionRunsMillis  value: 30  is not supported by 
DataSource: org.apache.commons.dbcp2.datasources.SharedPoolDataSource
12:33:09.571 [main] ERROR org.apache.torque.dsfactory.AbstractDataSourceFactory 
- Property: minEvictableIdleTimeMillis  value: 360  is not supported by 
DataSource: org.apache.commons.dbcp2.datasources.SharedPoolDataSource {code}
 
The reference says those properties exist: 
[https://commons.apache.org/proper/commons-dbcp/configuration.html]
 
Am I missing something here? As you can see, I use the MariaDB JDBC Driver, but 
I don't think this has effects to the pool properties?


> SharedPool2DataSourceFactory says property is not supported
> ---
>
> Key: TORQUE-362
> URL: https://issues.apache.org/jira/browse/TORQUE-362
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Minor
>  Labels: SharedPool2DataSourceFactory
>
> When I set properties like:
> {code:java}
> torque.dsfactory.test.pool.maxTotal = 20
> torque.dsfactory.test.pool.maxIdle = 15
> torque.dsfactory.test.pool.maxWaitMillis = 1
> torque.dsfactory.test.pool.timeBetweenEvictionRunsMillis = 30
> torque.dsfactory.test.pool.minEvictableIdleTimeMillis = 360
> // rest of config for reference
> torque.database.default = test
> torque.dsfactory.hvp.factory = 
> org.apache.torque.dsfactory.SharedPool2DataSourceFactory
> t

[jira] [Comment Edited] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt edited comment on TORQUE-361 at 3/8/23 11:49 AM:


I will test this in the near future. Hadn't found the time for it by now.

But a question in between (maybe a little off-topic):
Inside Jira version 5.1 is defined as "unreleased". In 
[Downloads|https://db.apache.org/torque/torque-5.1/download.html] it is 
released.

There is also an issue with the 5.1 templates download.


was (Author: JIRAUSER299058):
I will test this in the near future. Hadn't found the time for it by now.

But a question in between (maybe a little off-topic:
Inside Jira version 5.1 is defined as "unreleased". In 
[Downloads|https://db.apache.org/torque/torque-5.1/download.html] it is 
released.

There is also an issue with the 5.1 templates download.

> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: groovy
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve class 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt commented on TORQUE-361:
---

I will test this in the near future. Hadn't found the time for it by now.

But a question in between (maybe a little off-topic:
Inside Jira version 5.1 is defined as "unreleased". In 
[Downloads|https://db.apache.org/torque/torque-5.1/download.html] it is 
released.

There is also an issue with the 5.1 templates download.

> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: groovy
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve class 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-362) SharedPool2DataSourceFactory says property is not supported

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-362:
--
Affects Version/s: 5.1

> SharedPool2DataSourceFactory says property is not supported
> ---
>
> Key: TORQUE-362
> URL: https://issues.apache.org/jira/browse/TORQUE-362
> Project: Torque
>  Issue Type: Bug
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Minor
>
> When I set properties like:
> {code:java}
> torque.dsfactory.test.pool.maxTotal = 20
> torque.dsfactory.test.pool.maxIdle = 15
> torque.dsfactory.test.pool.maxWaitMillis = 1
> torque.dsfactory.test.pool.timeBetweenEvictionRunsMillis = 30
> torque.dsfactory.test.pool.minEvictableIdleTimeMillis = 360
> // rest of config for reference
> torque.database.default = test
> torque.dsfactory.hvp.factory = 
> org.apache.torque.dsfactory.SharedPool2DataSourceFactory
> torque.database.hvp.adapter = mysql
> torque.dsfactory.test.connection.driver = org.mariadb.jdbc.Driver
> torque.dsfactory.test.connection.url = jdbc:mariadb://localhost:3306/hvp
> torque.dsfactory.test.connection.user = user
> torque.dsfactory.test.connection.password = password{code}
> the initialization throws:
>  
> {code:java}
> 12:33:09.565 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: maxIdle  
> value: 15  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.570 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> maxWaitMillis  value: 1  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.570 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> timeBetweenEvictionRunsMillis  value: 30  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.571 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> minEvictableIdleTimeMillis  value: 360  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource {code}
>  
> The reference says those properties exist: 
> [https://commons.apache.org/proper/commons-dbcp/configuration.html]
>  
> Am I missing something here? As you can see, I use the MariaDB JDBC Driver, 
> but I don't think this has effects to the pool properties?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-362) SharedPool2DataSourceFactory says property is not supported

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-362:
--
Labels: SharedPool2DataSourceFactory  (was: )

> SharedPool2DataSourceFactory says property is not supported
> ---
>
> Key: TORQUE-362
> URL: https://issues.apache.org/jira/browse/TORQUE-362
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Minor
>  Labels: SharedPool2DataSourceFactory
>
> When I set properties like:
> {code:java}
> torque.dsfactory.test.pool.maxTotal = 20
> torque.dsfactory.test.pool.maxIdle = 15
> torque.dsfactory.test.pool.maxWaitMillis = 1
> torque.dsfactory.test.pool.timeBetweenEvictionRunsMillis = 30
> torque.dsfactory.test.pool.minEvictableIdleTimeMillis = 360
> // rest of config for reference
> torque.database.default = test
> torque.dsfactory.hvp.factory = 
> org.apache.torque.dsfactory.SharedPool2DataSourceFactory
> torque.database.hvp.adapter = mysql
> torque.dsfactory.test.connection.driver = org.mariadb.jdbc.Driver
> torque.dsfactory.test.connection.url = jdbc:mariadb://localhost:3306/hvp
> torque.dsfactory.test.connection.user = user
> torque.dsfactory.test.connection.password = password{code}
> the initialization throws:
>  
> {code:java}
> 12:33:09.565 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: maxIdle  
> value: 15  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.570 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> maxWaitMillis  value: 1  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.570 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> timeBetweenEvictionRunsMillis  value: 30  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.571 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> minEvictableIdleTimeMillis  value: 360  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource {code}
>  
> The reference says those properties exist: 
> [https://commons.apache.org/proper/commons-dbcp/configuration.html]
>  
> Am I missing something here? As you can see, I use the MariaDB JDBC Driver, 
> but I don't think this has effects to the pool properties?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-362) SharedPool2DataSourceFactory says property is not supported

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-362:
--
Description: 
When I set properties like:
{code:java}
torque.dsfactory.test.pool.maxTotal = 20
torque.dsfactory.test.pool.maxIdle = 15
torque.dsfactory.test.pool.maxWaitMillis = 1
torque.dsfactory.test.pool.timeBetweenEvictionRunsMillis = 30
torque.dsfactory.test.pool.minEvictableIdleTimeMillis = 360
// rest of config for reference
torque.database.default = test
torque.dsfactory.hvp.factory = 
org.apache.torque.dsfactory.SharedPool2DataSourceFactory
torque.database.hvp.adapter = mysql
torque.dsfactory.test.connection.driver = org.mariadb.jdbc.Driver
torque.dsfactory.test.connection.url = jdbc:mariadb://localhost:3306/hvp
torque.dsfactory.test.connection.user = user
torque.dsfactory.test.connection.password = password{code}
the initialization throws:

 
{code:java}
12:33:09.565 [main] ERROR org.apache.torque.dsfactory.AbstractDataSourceFactory 
- Property: maxIdle  value: 15  is not supported by DataSource: 
org.apache.commons.dbcp2.datasources.SharedPoolDataSource
12:33:09.570 [main] ERROR org.apache.torque.dsfactory.AbstractDataSourceFactory 
- Property: maxWaitMillis  value: 1  is not supported by DataSource: 
org.apache.commons.dbcp2.datasources.SharedPoolDataSource
12:33:09.570 [main] ERROR org.apache.torque.dsfactory.AbstractDataSourceFactory 
- Property: timeBetweenEvictionRunsMillis  value: 30  is not supported by 
DataSource: org.apache.commons.dbcp2.datasources.SharedPoolDataSource
12:33:09.571 [main] ERROR org.apache.torque.dsfactory.AbstractDataSourceFactory 
- Property: minEvictableIdleTimeMillis  value: 360  is not supported by 
DataSource: org.apache.commons.dbcp2.datasources.SharedPoolDataSource {code}
 
The reference says those properties exist: 
[https://commons.apache.org/proper/commons-dbcp/configuration.html]
 
Am I missing something here? As you can see, I use the MariaDB JDBC Driver, but 
I don't think this has effects to the pool properties?

> SharedPool2DataSourceFactory says property is not supported
> ---
>
> Key: TORQUE-362
> URL: https://issues.apache.org/jira/browse/TORQUE-362
> Project: Torque
>  Issue Type: Bug
>Reporter: Max Philipp Wriedt
>Priority: Minor
>
> When I set properties like:
> {code:java}
> torque.dsfactory.test.pool.maxTotal = 20
> torque.dsfactory.test.pool.maxIdle = 15
> torque.dsfactory.test.pool.maxWaitMillis = 1
> torque.dsfactory.test.pool.timeBetweenEvictionRunsMillis = 30
> torque.dsfactory.test.pool.minEvictableIdleTimeMillis = 360
> // rest of config for reference
> torque.database.default = test
> torque.dsfactory.hvp.factory = 
> org.apache.torque.dsfactory.SharedPool2DataSourceFactory
> torque.database.hvp.adapter = mysql
> torque.dsfactory.test.connection.driver = org.mariadb.jdbc.Driver
> torque.dsfactory.test.connection.url = jdbc:mariadb://localhost:3306/hvp
> torque.dsfactory.test.connection.user = user
> torque.dsfactory.test.connection.password = password{code}
> the initialization throws:
>  
> {code:java}
> 12:33:09.565 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: maxIdle  
> value: 15  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.570 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> maxWaitMillis  value: 1  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.570 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> timeBetweenEvictionRunsMillis  value: 30  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.571 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> minEvictableIdleTimeMillis  value: 360  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource {code}
>  
> The reference says those properties exist: 
> [https://commons.apache.org/proper/commons-dbcp/configuration.html]
>  
> Am I missing something here? As you can see, I use the MariaDB JDBC Driver, 
> but I don't think this has effects to the pool properties?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-362) SharedPool2DataSourceFactory says property is not supported

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-362:
--
Component/s: Runtime

> SharedPool2DataSourceFactory says property is not supported
> ---
>
> Key: TORQUE-362
> URL: https://issues.apache.org/jira/browse/TORQUE-362
> Project: Torque
>  Issue Type: Bug
>  Components: Runtime
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Minor
>
> When I set properties like:
> {code:java}
> torque.dsfactory.test.pool.maxTotal = 20
> torque.dsfactory.test.pool.maxIdle = 15
> torque.dsfactory.test.pool.maxWaitMillis = 1
> torque.dsfactory.test.pool.timeBetweenEvictionRunsMillis = 30
> torque.dsfactory.test.pool.minEvictableIdleTimeMillis = 360
> // rest of config for reference
> torque.database.default = test
> torque.dsfactory.hvp.factory = 
> org.apache.torque.dsfactory.SharedPool2DataSourceFactory
> torque.database.hvp.adapter = mysql
> torque.dsfactory.test.connection.driver = org.mariadb.jdbc.Driver
> torque.dsfactory.test.connection.url = jdbc:mariadb://localhost:3306/hvp
> torque.dsfactory.test.connection.user = user
> torque.dsfactory.test.connection.password = password{code}
> the initialization throws:
>  
> {code:java}
> 12:33:09.565 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: maxIdle  
> value: 15  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.570 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> maxWaitMillis  value: 1  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.570 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> timeBetweenEvictionRunsMillis  value: 30  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource
> 12:33:09.571 [main] ERROR 
> org.apache.torque.dsfactory.AbstractDataSourceFactory - Property: 
> minEvictableIdleTimeMillis  value: 360  is not supported by DataSource: 
> org.apache.commons.dbcp2.datasources.SharedPoolDataSource {code}
>  
> The reference says those properties exist: 
> [https://commons.apache.org/proper/commons-dbcp/configuration.html]
>  
> Am I missing something here? As you can see, I use the MariaDB JDBC Driver, 
> but I don't think this has effects to the pool properties?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-362) SharedPool2DataSourceFactory says property is not supported

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-362:
--
Priority: Minor  (was: Major)

> SharedPool2DataSourceFactory says property is not supported
> ---
>
> Key: TORQUE-362
> URL: https://issues.apache.org/jira/browse/TORQUE-362
> Project: Torque
>  Issue Type: Bug
>Reporter: Max Philipp Wriedt
>Priority: Minor
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Created] (TORQUE-362) SharedPool2DataSourceFactory says property is not supported

[Max Philipp Wriedt (Jira)]

Max Philipp Wriedt created TORQUE-362:
-

 Summary: SharedPool2DataSourceFactory says property is not 
supported
 Key: TORQUE-362
 URL: https://issues.apache.org/jira/browse/TORQUE-362
 Project: Torque
  Issue Type: Bug
Reporter: Max Philipp Wriedt






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt commented on TORQUE-361:
---

I am currently developing a gradle plugin for torque generation. The gradle 
version is 8.0.1
https://git.rehost.eu/rehost/gradle-torque

I am using the code from „Running the generator“ converted to Kotlin.

When printing the classpath from systemproperties I only get the 
gradle-launcher.jar. When printing the classpath from contextClassLoader() I 
get the full and correct classpath.

I tried setting the classloader as u described. In my case the GroovyShell 
wasn‘t using it and stayed on the wrong systemproperty class.path.
The TorqueGenerator itself used the UnitDescriptor.classLoader (tested with 
removing the templates, which couldn‘t be found after removing from 
URLClassPath)

> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: groovy
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve class 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
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-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt edited comment on TORQUE-361 at 3/2/23 5:21 PM:
---

I am currently developing a gradle plugin for torque generation. The gradle 
version is 8.0.1
https://git.rehost.eu/rehost/gradle-torque

I am using the code from „Running the generator“ converted to Kotlin.

When printing the classpath from systemproperties I only get the 
gradle-launcher.jar. When printing the classpath from contextClassLoader() I 
get the full and correct classpath.

I tried setting the classloader as you described. In my case the GroovyShell 
wasn‘t using it and stayed on the wrong systemproperty class.path.
The TorqueGenerator itself used the UnitDescriptor.classLoader (tested with 
removing the templates, which couldn‘t be found after removing from 
URLClassPath)


was (Author: JIRAUSER299058):
I am currently developing a gradle plugin for torque generation. The gradle 
version is 8.0.1
https://git.rehost.eu/rehost/gradle-torque

I am using the code from „Running the generator“ converted to Kotlin.

When printing the classpath from systemproperties I only get the 
gradle-launcher.jar. When printing the classpath from contextClassLoader() I 
get the full and correct classpath.

I tried setting the classloader as u described. In my case the GroovyShell 
wasn‘t using it and stayed on the wrong systemproperty class.path.
The TorqueGenerator itself used the UnitDescriptor.classLoader (tested with 
removing the templates, which couldn‘t be found after removing from 
URLClassPath)

> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: groovy
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve class 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-361:
--
Affects Version/s: 5.0

> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 5.0, 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: groovy
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve class 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-361:
--
Component/s: Generator

> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve class 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-361:
--
Labels: groovy  (was: )

> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>  Labels: groovy
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve class 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-361:
--
Affects Version/s: 5.1

> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>Affects Versions: 5.1
>Reporter: Max Philipp Wriedt
>Priority: Major
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve class 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-361:
--
Description: 
The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a classpath, 
if i try to start it from a gradle instance. (the generator is invoked inside a 
kotlin.class)
{code:java}
Error executing template torque.sql.ddl.database
org.apache.torque.generator.GeneratorException: Error executing template 
torque.sql.ddl.database
Caused by: org.apache.torque.generator.GeneratorException: Error executing 
groovy script torque.sql.ddl.database
Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
startup failed:
Script1.groovy: 17: unable to resolve class 
org.apache.torque.generator.template.groovy.TorqueGenGroovy
 @ line 17, column 1.
   import org.apache.torque.generator.template.groovy.TorqueGenGroovy
   ^{code}

  was:
The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a classpath, 
if i try to start it from a gradle instance. (the generator is invoked inside a 
kotlin.class)
{code:java}
Error executing template torque.sql.ddl.database
org.apache.torque.generator.GeneratorException: Error executing template 
torque.sql.ddl.database
Caused by: org.apache.torque.generator.GeneratorException: Error executing 
groovy script torque.sql.ddl.database
Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
startup failed:
Script1.groovy: 17: unable to resolve cl ass 
org.apache.torque.generator.template.groovy.TorqueGenGroovy
 @ line 17, column 1.
   import org.apache.torque.generator.template.groovy.TorqueGenGroovy
   ^{code}


> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>Reporter: Max Philipp Wriedt
>Priority: Major
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve class 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

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

Max Philipp Wriedt commented on TORQUE-361:
---

My fix was to change GroovyScriptOutlet:42 from
{code:java}
private static GroovyShell groovyShell = new GroovyShell(); {code}
to
{code:java}
private static GroovyShell groovyShell = new 
GroovyShell(Thread.currentThread().getContextClassLoader()); {code}
as this invokes the GroovyShell including the ClassLoader given by the 
Kotlin.class which is started by gradle

> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>Reporter: Max Philipp Wriedt
>Priority: Major
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve cl ass 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-361:
--
Description: 
The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a classpath, 
if i try to start it from a gradle instance. (the generator is invoked inside a 
kotlin.class)
{code:java}
Error executing template torque.sql.ddl.database
org.apache.torque.generator.GeneratorException: Error executing template 
torque.sql.ddl.database
Caused by: org.apache.torque.generator.GeneratorException: Error executing 
groovy script torque.sql.ddl.database
Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
startup failed:
Script1.groovy: 17: unable to resolve cl ass 
org.apache.torque.generator.template.groovy.TorqueGenGroovy
 @ line 17, column 1.
   import org.apache.torque.generator.template.groovy.TorqueGenGroovy
   ^{code}

  was:
The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a classpath, 
if i try to start it from a gradle instance.
{code:java}
Error executing template torque.sql.ddl.database
org.apache.torque.generator.GeneratorException: Error executing template 
torque.sql.ddl.database
Caused by: org.apache.torque.generator.GeneratorException: Error executing 
groovy script torque.sql.ddl.database
Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
startup failed:
Script1.groovy: 17: unable to resolve cl ass 
org.apache.torque.generator.template.groovy.TorqueGenGroovy
 @ line 17, column 1.
   import org.apache.torque.generator.template.groovy.TorqueGenGroovy
   ^{code}


> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>Reporter: Max Philipp Wriedt
>Priority: Major
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance. (the generator is 
> invoked inside a kotlin.class)
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve cl ass 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

 [ 
https://issues.apache.org/jira/browse/TORQUE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Philipp Wriedt updated TORQUE-361:
--
Description: 
The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a classpath, 
if i try to start it from a gradle instance.
{code:java}
Error executing template torque.sql.ddl.database
org.apache.torque.generator.GeneratorException: Error executing template 
torque.sql.ddl.database
Caused by: org.apache.torque.generator.GeneratorException: Error executing 
groovy script torque.sql.ddl.database
Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
startup failed:
Script1.groovy: 17: unable to resolve cl ass 
org.apache.torque.generator.template.groovy.TorqueGenGroovy
 @ line 17, column 1.
   import org.apache.torque.generator.template.groovy.TorqueGenGroovy
   ^{code}

> Groovy can't resolve import from ddl scripts
> 
>
> Key: TORQUE-361
> URL: https://issues.apache.org/jira/browse/TORQUE-361
> Project: Torque
>  Issue Type: Bug
>Reporter: Max Philipp Wriedt
>Priority: Major
>
> The GroovyShell invoked at GroovyScriptOutlet.java:42 doesn't get a 
> classpath, if i try to start it from a gradle instance.
> {code:java}
> Error executing template torque.sql.ddl.database
> org.apache.torque.generator.GeneratorException: Error executing template 
> torque.sql.ddl.database
> Caused by: org.apache.torque.generator.GeneratorException: Error executing 
> groovy script torque.sql.ddl.database
> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
> startup failed:
> Script1.groovy: 17: unable to resolve cl ass 
> org.apache.torque.generator.template.groovy.TorqueGenGroovy
>  @ line 17, column 1.
>    import org.apache.torque.generator.template.groovy.TorqueGenGroovy
>    ^{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Created] (TORQUE-361) Groovy can't resolve import from ddl scripts

[Max Philipp Wriedt (Jira)]

Max Philipp Wriedt created TORQUE-361:
-

 Summary: Groovy can't resolve import from ddl scripts
 Key: TORQUE-361
 URL: https://issues.apache.org/jira/browse/TORQUE-361
 Project: Torque
  Issue Type: Bug
Reporter: Max Philipp Wriedt






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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