[jira] [Commented] (TORQUE-343) Implement a central registry for peerImpls like the registry for managers
[
https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15400384#comment-15400384
]
Thomas Fox commented on TORQUE-343:
---
Sorry for pestering you with questions. Go ahead. I'm just fayouring storing
information locally instead of having registries where one always wonders when
the information is written there, so my intention was to grasp the motivation.
> Implement a central registry for peerImpls like the registry for managers
> -
>
> Key: TORQUE-343
> URL: https://issues.apache.org/jira/browse/TORQUE-343
> Project: Torque
> Issue Type: Improvement
> Components: Runtime, Templates
>Affects Versions: 4.0
>Reporter: Thomas Vandahl
>Assignee: Thomas Vandahl
> Fix For: 4.1
>
>
> I'd like to suggest a central registry for peerImpl-objects which can be
> queried by the Persistent class it is responsible for. This would allow
> reusing and extending the peer objects dynamically as well as giving them
> some kind of life-cycle.
> The main method would be similar to this:
> {code:java}
> public BasePeerImpl getPeerFor(Class persistentClass)
> {
> return peerRegistry.get(persistentClass);
> }
> {code}
> I would also like to suggest moving the buildCriteria(obj) method to the
> RecordMapper or the TableMap class. This will further reduce the amount of
> code that needs to be generated.
> If the idea is received well, I'll come up with a proposal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-346) Introduce abstract layer for peer impl to reduce the amount of generated code
[ https://issues.apache.org/jira/browse/TORQUE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15400381#comment-15400381 ] Thomas Fox commented on TORQUE-346: --- I'm not sure what you mena by "availability of a primary key". If you mean that the object is already in dthe database and thus has a primary key, the answer is no (see e.g. org.apache.torque.test.dbobject.base.BaseExt in the test project, which has a primitive primary key which always is set and thus obj.getPrimaryKey() will never return null). If you mean whether the table has a PK at all, this will probably work currently, although it is not documented. However, for me it would be cleaner to store this information in the table map instead of relying on the obj.getPrimaryKey() method. > Introduce abstract layer for peer impl to reduce the amount of generated code > - > > Key: TORQUE-346 > URL: https://issues.apache.org/jira/browse/TORQUE-346 > Project: Torque > Issue Type: Improvement > Components: Runtime, Templates >Affects Versions: 4.0 >Reporter: Thomas Vandahl >Assignee: Thomas Vandahl > Fix For: 4.1 > > > Several methods in PeerImpl rely on buildCriteria() and buildColumnValues() > respectively. An intermediate layer of AbstractPeerImpl can be used to > concentrate these methods in a central class and reduce the amount of > generated code duplication. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-346) Introduce abstract layer for peer impl to reduce the amount of generated code
[ https://issues.apache.org/jira/browse/TORQUE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15395060#comment-15395060 ] Thomas Fox commented on TORQUE-346: --- In a normal Torque setup, if you call SomePeer.doDelete(someObject), there is no marker that the Object is deleted in the object. torque.om.trackDeleted=true adds such a marker. > Introduce abstract layer for peer impl to reduce the amount of generated code > - > > Key: TORQUE-346 > URL: https://issues.apache.org/jira/browse/TORQUE-346 > Project: Torque > Issue Type: Improvement > Components: Runtime, Templates >Affects Versions: 4.0 >Reporter: Thomas Vandahl >Assignee: Thomas Vandahl > Fix For: 4.1 > > > Several methods in PeerImpl rely on buildCriteria() and buildColumnValues() > respectively. An intermediate layer of AbstractPeerImpl can be used to > concentrate these methods in a central class and reduce the amount of > generated code duplication. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-343) Implement a central registry for peerImpls like the registry for managers
[
https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15395057#comment-15395057
]
Thomas Fox commented on TORQUE-343:
---
Let me see if I grasp the fulcrum case:
- There is a FulcrumUser object provided py fulcrum and the implementer wants
an attribute in the User object which is not in BaseUser, so an Object User
extends FulcrumUser is created which has the additional attribute. But then,
the Peer class must need to know how to read and write this attribute from/to
the database, so the FulcrumUserPeer needs to be extended as well? I do not see
a way to get around that...
Regarding the complex query use case, there are two places where you need to
write code:
- The composition of the Query, which would by convention be in the Peer class
- The mapping of the Query Result to the object, which would by convention be
in the Record Mapper
What is the reason why you use separate classes? And if you use separate
classes, is there still only one peer for one object class?
No objection against moving code to a generated BaseAbstractPeerImpl (or
whatever you call it :-) )
> Implement a central registry for peerImpls like the registry for managers
> -
>
> Key: TORQUE-343
> URL: https://issues.apache.org/jira/browse/TORQUE-343
> Project: Torque
> Issue Type: Improvement
> Components: Runtime, Templates
>Affects Versions: 4.0
>Reporter: Thomas Vandahl
>Assignee: Thomas Vandahl
> Fix For: 4.1
>
>
> I'd like to suggest a central registry for peerImpl-objects which can be
> queried by the Persistent class it is responsible for. This would allow
> reusing and extending the peer objects dynamically as well as giving them
> some kind of life-cycle.
> The main method would be similar to this:
> {code:java}
> public BasePeerImpl getPeerFor(Class persistentClass)
> {
> return peerRegistry.get(persistentClass);
> }
> {code}
> I would also like to suggest moving the buildCriteria(obj) method to the
> RecordMapper or the TableMap class. This will further reduce the amount of
> code that needs to be generated.
> If the idea is received well, I'll come up with a proposal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-343) Implement a central registry for peerImpls like the registry for managers
[
https://issues.apache.org/jira/browse/TORQUE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1524#comment-1524
]
Thomas Fox commented on TORQUE-343:
---
You can already dynamically extend and exchange the PeerImpls by
SomePeer.setSomePeerImpl() method. It is already kind of a distributed
registry. Would the SomePeers query the registry instead of storing the
PeerImpls locally?
Also a central registry has the problem of type safety. The PeerImpls are
currently generic, yet there are some methods which are generated for some
PeerImpls but not for others (e.g. retrieveByPK(String, int, String, Integer,
Byte, Short, Long, Double, Double, Date) is generated for BaseMultiPkPeerImpl
but not for BaseAuthorPeerImpl) which would require explicit casts if the type
of the returned PeerImpl is not known.
Where would the registry be used? If you can point to some use cases, I could
better make up my opinion.
As for moving the buildCriteria(obj) to the RecordMapper, I'd rather not do
this. Currently, a RecordMapper has the single purpose to map a database record
to the Object. So if one has as strange database structure one has to read, one
can easily implement the RecordMapper interface to perform the mapping
manually. See e.g. the clases in org.apache.torque.om.mapper. Moving other
functionality into this interface would impede this function in my opinion.
However, I'd rather suggest to cerate another object which is responsible for
creating the other way round (object to database) (name suggestion:
...Selector) which then would contain the buildCriteria(Object) method (as well
as perhaps the other build...CriteriaMethods). However this would again
increase the number of created classes, so I am not sure whether this does not
add too much complexity.
As for moving the buildCriteria(obj) to the table map: The table map is
currently not a generated class. How would you accesss the relevant getters for
the data object there?
Again, can you provide a reson why it would be favorable to move the
buildCriteria(obj) method?
> Implement a central registry for peerImpls like the registry for managers
> -
>
> Key: TORQUE-343
> URL: https://issues.apache.org/jira/browse/TORQUE-343
> Project: Torque
> Issue Type: Improvement
> Components: Runtime, Templates
>Affects Versions: 4.0
>Reporter: Thomas Vandahl
>Assignee: Thomas Vandahl
> Fix For: 4.1
>
>
> I'd like to suggest a central registry for peerImpl-objects which can be
> queried by the Persistent class it is responsible for. This would allow
> reusing and extending the peer objects dynamically as well as giving them
> some kind of life-cycle.
> The main method would be similar to this:
> {code:java}
> public BasePeerImpl getPeerFor(Class persistentClass)
> {
> return peerRegistry.get(persistentClass);
> }
> {code}
> I would also like to suggest moving the buildCriteria(obj) method to the
> RecordMapper or the TableMap class. This will further reduce the amount of
> code that needs to be generated.
> If the idea is received well, I'll come up with a proposal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Closed] (TORQUE-295) The configuration of the generator should be simplified
[ https://issues.apache.org/jira/browse/TORQUE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox closed TORQUE-295. - Resolution: Fixed Fix Version/s: 4.1 Unfortunately, no big possibilities for simplification were discovered until now. If there is anything other we can simplify, please simply open a new ticket with the suggestion. > The configuration of the generator should be simplified > --- > > Key: TORQUE-295 > URL: https://issues.apache.org/jira/browse/TORQUE-295 > Project: Torque > Issue Type: Improvement > Components: Generator, Templates >Affects Versions: 4.0 >Reporter: Thomas Fox > Fix For: 4.1 > > > Currently, it is no easy task to write templates for the generator. > This should be simplified where possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Closed] (TORQUE-281) Only issue SQL update with columns whose value is changed in dbObject, since it was loaded from db
[ https://issues.apache.org/jira/browse/TORQUE-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox closed TORQUE-281. - Resolution: Won't Fix Still nobyody wh wants to implement this. Please reopen the ticket if anybody wants to implement this. > Only issue SQL update with columns whose value is changed in dbObject, since > it was loaded from db > -- > > Key: TORQUE-281 > URL: https://issues.apache.org/jira/browse/TORQUE-281 > Project: Torque > Issue Type: Improvement >Reporter: rajguru > > This means dbObject needs to have a way to see oldValue and newValue. If so > also provide some hooks in the code before update/after update/before > insert/after insert/before delete and after delete, so one can plugin an > auditing code to log the oldValue to newValue change -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Closed] (TORQUE-340) Not all DBCP properties are supported for connection pools
[
https://issues.apache.org/jira/browse/TORQUE-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox closed TORQUE-340.
-
Resolution: Cannot Reproduce
Closing due to lack of response. Please reopen if there are any new insights
which are not covered by the response above.
> Not all DBCP properties are supported for connection pools
> --
>
> Key: TORQUE-340
> URL: https://issues.apache.org/jira/browse/TORQUE-340
> Project: Torque
> Issue Type: New Feature
> Components: Runtime
>Affects Versions: 4.0
>Reporter: Rob Decker
>Priority: Minor
>
> While the documentation for SharedPoolDataSourceFactory referes to the DBCP
> documentation (http://commons.apache.org/dbcp/configuration.html) for
> properties that can be set I tried to use connectionInitSqls (and the form
> connectInitSqls) and it is not supported:
> Property: connectionInitSqls value: BEGIN;DBMS_SESSION.SET_NLS('NLS_COMP' is
> not supported by DataSource:
> org.apache.commons.dbcp.datasources.SharedPoolDataSource
> It would be nice if it supported this as it's a simple way to get
> case-insensitive queries in Oracle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-342) XXXPeer.addSelectColumns() is declared to throw TorqueException for no apparent reason
[
https://issues.apache.org/jira/browse/TORQUE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15174391#comment-15174391
]
Thomas Fox commented on TORQUE-342:
---
Removing the throws clause in generation can break compiletime compatibility,
casue TorqueException is a checked exception, and if it is the only occurence
in a catch block the compiler will throw an error.
However I am fine with removing the throws declaration in the template because
the change would clarify that no TorqueException will ever be thrown there.
> XXXPeer.addSelectColumns() is declared to throw TorqueException for no
> apparent reason
> --
>
> Key: TORQUE-342
> URL: https://issues.apache.org/jira/browse/TORQUE-342
> Project: Torque
> Issue Type: Improvement
> Components: Templates
>Affects Versions: 4.0
>Reporter: Thomas Vandahl
>Priority: Minor
> Fix For: 4.1
>
>
> For example {{AuthorPeer.addSelectColumns()}} is declared as
> {code:java}
> public static void addSelectColumns(Criteria criteria)
> throws TorqueException
> {
> getAuthorPeerImpl().addSelectColumns(criteria);
> }
> {code}
> {{getAuthorPeerImpl().addSelectColumns(criteria)}}, however actually calls
> {{BasePeerImpl.addSelectColumns(criteria)}} which does not throw any
> exceptions. Is this a leftover from previous times when the columns were
> drawn from the MapBuilders?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-108) Criteria addJoin causes incorrect SQL to be generated when optional schema references are in use (Oracle)
[
https://issues.apache.org/jira/browse/TORQUE-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14970604#comment-14970604
]
Thomas Fox commented on TORQUE-108:
---
If you want, can you provide your test so it can be added to the torte test
suite ? Please reopen the ticket if you do so.
As for the ColumnImpl, the reason why this was introdiced is that if you do
criteria.add("test","value") there is no way of telling whteher "test" and
"value" are table columns or verbatim values. ColumnImpl provides a clean
distiction: all ColumnImpl objects are columns, and all String fields are
verbatim values.
> Criteria addJoin causes incorrect SQL to be generated when optional schema
> references are in use (Oracle)
> -
>
> Key: TORQUE-108
> URL: https://issues.apache.org/jira/browse/TORQUE-108
> Project: Torque
> Issue Type: Bug
> Components: Runtime
>Affects Versions: 3.3-RC1, 3.3-RC2, 3.3-RC3
> Environment: Linux, Java 1.6
>Reporter: Brendan Miller
>Assignee: Thomas Fox
> Fix For: 4.0-beta1
>
> Attachments: JoinBuilderTest.java, joinbuilder.patch
>
>
> I previously wrote about this to torque-user in Oct 2007.
> In a schema definition that includes torque.dsfactory.programs.schema,
> writing the following
> Criteria crit = new Criteria();
> crit.addJoin(TransactionPeer.ORDER_ID, OrderPeer.ID);
> crit.add(TransactionPeer.ACCT_ID, account.getID());
> List orders = OrderPeer.doSelect(crit);
> generates
> SELECT <..ORDERS columns..> FROM TRANSACTION, ORDERS, DBSCHEMA.ORDERS,
> DBSCHEMA.TRANSACTION
> WHERE TRANSACTION.ORDER_ID=ORDERS.ID AND TRANSACTION.ACCT_ID= ?
> Upon examining the Torque code, it appears that SQLBuilder.processJoins does
> not add the full table names, while SQLBuilder.processCriterions does.
> Shouldn't they both add the full table names?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-340) Not all DBCP properties are supported for connection pools
[
https://issues.apache.org/jira/browse/TORQUE-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14953659#comment-14953659
]
Thomas Fox commented on TORQUE-340:
---
If I did not overlook something, the connectionInitSqls attribute is only an
attribute of DBCP's BasicDataSource, not of DBCP's SharedPoolDataSource which
you are using. Even in the newest DBCP package (2.1.1, which cannot be used
currently in Torque because of java 1.6 compatibility of the runtime) I did not
see an equivalent attribute in SharedPoolDataSource.
So it's not something that Torque misses, but it seems that it is a DBCP
Problem. Have you tried to ask at the dbcp users mailing list?
Also, note that you can use any data source you want in Torque. You can
implement the interface org.apache.torque.dsfactory.DataSourceFactory and use
the class name as dsfactory value in the Torque configuration. So you can also
use a BasicDataSource (with the config parameter you need) if you want to.
Sorry, but due to lack of support in commons-dbcp, I can see no easy way to set
connection properties only once in Torque. Other alternatives I have found are
using a logon trigger (
e.g.
http://forum.spring.io/forum/spring-projects/data/102188-best-way-to-set-nls-sort-for-oracle)
or using Torque's support for case insensitive Queries
(Criteria.setIgnoreCase).
Is the above acceptable for you?
> Not all DBCP properties are supported for connection pools
> --
>
> Key: TORQUE-340
> URL: https://issues.apache.org/jira/browse/TORQUE-340
> Project: Torque
> Issue Type: New Feature
> Components: Runtime
>Affects Versions: 4.0
>Reporter: Rob Decker
>Priority: Minor
>
> While the documentation for SharedPoolDataSourceFactory referes to the DBCP
> documentation (http://commons.apache.org/dbcp/configuration.html) for
> properties that can be set I tried to use connectionInitSqls (and the form
> connectInitSqls) and it is not supported:
> Property: connectionInitSqls value: BEGIN;DBMS_SESSION.SET_NLS('NLS_COMP' is
> not supported by DataSource:
> org.apache.commons.dbcp.datasources.SharedPoolDataSource
> It would be nice if it supported this as it's a simple way to get
> case-insensitive queries in Oracle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-337) Add ability to easily configure logging for the generator
[
https://issues.apache.org/jira/browse/TORQUE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14952537#comment-14952537
]
Thomas Fox commented on TORQUE-337:
---
Though I can see the need for overriding the internal log configuration file, I
am not convinced by the solution above. This requires a logger with a special
name in the log configuration file, which is too much magic involved in my
opinion.
I'd rather have a setting which tells the generator to use another log4j config
file. My first idea would be to add another attribute to the control tag in the
control.xml file (as there's already the loglevel attribute). What do you think?
> Add ability to easily configure logging for the generator
> -
>
> Key: TORQUE-337
> URL: https://issues.apache.org/jira/browse/TORQUE-337
> Project: Torque
> Issue Type: Improvement
> Components: Generator
>Affects Versions: 4.1
>Reporter: Helge Weissig
>
> The patch below allows for the easy configuration of logging for the
> generator. For example, using maven, the internal log4j.properties shipped
> with the torque-generator artifact can be overridden by including the command
> line flag '-Dlog4j.properties=file:/'.
> patch:
> {code}
> Index:
> torque-generator/src/main/java/org/apache/torque/generator/control/Controller.java
> ===
> ---
> torque-generator/src/main/java/org/apache/torque/generator/control/Controller.java
> (revision 1689921)
> +++
> torque-generator/src/main/java/org/apache/torque/generator/control/Controller.java
> (working copy)
> @@ -35,6 +35,8 @@
>
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
> +import org.apache.log4j.LogManager;
> +import org.apache.log4j.Logger;
> import org.apache.log4j.PropertyConfigurator;
> import org.apache.torque.generator.GeneratorException;
> import org.apache.torque.generator.configuration.Configuration;
> @@ -152,19 +154,29 @@
> */
> protected void initLogging()
> {
> -final InputStream log4jStream
> -= Controller.class.getClassLoader().getResourceAsStream(
> -"org/apache/torque/generator/log4j.properties");
> -final Properties log4jProperties = new Properties();
> -try
> +Logger logger = LogManager.exists("org.apache.torque.generator");
> +if (logger == null)
> {
> -log4jProperties.load(log4jStream);
> +log.info("Configuring logging from internal log4j.properties");
> +final InputStream log4jStream =
> +Controller.class.getClassLoader().getResourceAsStream(
> +"org/apache/torque/generator/log4j.properties");
> +final Properties log4jProperties = new Properties();
> +
> +try
> +{
> +log4jProperties.load(log4jStream);
> +}
> +catch (final IOException e) {
> +throw new RuntimeException(e);
> +}
> +
> +PropertyConfigurator.configure(log4jProperties);
> }
> -catch (final IOException e)
> +else
> {
> -throw new RuntimeException(e);
> +log.warn("Using external logging configuration");
> }
> -PropertyConfigurator.configure(log4jProperties);
> }
>
> /**
> {code}
> example log4j.properties:
> {code}
> ## modify logging for the chatty Torque generator
> log4j.logger.org.apache.torque.generator = INFO, generator, console
> log4j.appender.generator = org.apache.log4j.FileAppender
> log4j.appender.generator.file = target/torque-gen/log/torque-gen.log
> log4j.appender.generator.append = true
> log4j.appender.generator.layout = org.apache.log4j.PatternLayout
> log4j.appender.generator.layout.conversionPattern = %d [%t] %-5p %c - %m%n
> log4j.appender.console = org.apache.log4j.ConsoleAppender
> log4j.appender.console.layout = org.apache.log4j.PatternLayout
> log4j.appender.console.layout.conversionPattern = %-5p %c - %m%n
> log4j.appender.console.threshold = WARN
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-290) Improve building from clause in subselect
[
https://issues.apache.org/jira/browse/TORQUE-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox resolved TORQUE-290.
---
Resolution: Fixed
Fix Version/s: 4.1
A Mixture between Strategy 1 and 2 was used.
A special element for the subselect was inserted in the generated query which
can look at the outer query. At the time the inner query is rendered, the outer
query already has its FROM clause ready, and so one can remove the duplicate
tables from the subselect's FROM clause when rendering
> Improve building from clause in subselect
> -
>
> Key: TORQUE-290
> URL: https://issues.apache.org/jira/browse/TORQUE-290
> Project: Torque
> Issue Type: Improvement
> Components: Runtime
>Affects Versions: 4.0
>Reporter: Thomas Fox
>Assignee: Thomas Fox
> Labels: incompatibleChange
> Fix For: 4.1
>
>
> Currently, it is not easily possible to reference columns in the main select
> from a subselect.
> For example, to select authors which have published exactly one book, one can
> use the SQL:
> SELECT * FROM author WHERE (SELECT COUNT(*) FROM book WHERE
> book.author_id=author.author_id)=1
> One would like to achieve this by
> Criteria subselect = new Criteria();
> subselect.where(BookPeer.AUTHOR_ID, AuthorPeer.AUTHOR_ID);
> subselect.addSelectColumn(new Count("*"));
> Criteria criteria = new Criteria();
> criteria.where(subselect, 1);
> List result = AuthorPeer.doSelect(criteria);
> but the SQL results in (note the additional author in the from clause of the
> subselect)
> SELECT * FROM author WHERE (SELECT COUNT(*) FROM book, author WHERE
> book.author_id=author.author_id)=1
> So the desired behavior is:
> If a table also exists in the from clause of the outer criteria, it should
> not be added to the from clause of the subselect
> NOTE1: This change can change the behaviour of Torque in existing code
> NOTE2: Workarounds exist, e.g. defining the FROM clause of the subselect
> manually using Criteria.addFrom() or using "new
> ColumnImpl(null,null,null,AuthorPeer.AUTHOR_ID.getSqlExpression())" as join
> column in the WHERE clause of the subselect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-341) Make PreparedStatementPart an interface
Thomas Fox created TORQUE-341: - Summary: Make PreparedStatementPart an interface Key: TORQUE-341 URL: https://issues.apache.org/jira/browse/TORQUE-341 Project: Torque Issue Type: Sub-task Components: Runtime Reporter: Thomas Fox Assignee: Thomas Fox Fix For: 4.1 To retain information about the query in the created query, PreparedStatementPart should be made an interface. The current implementation of PreparedStatementPart should be moved to org.apache.torque.criteria.PreparedStatementPartImpl -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-341) Make PreparedStatementPart an interface
[ https://issues.apache.org/jira/browse/TORQUE-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-341. --- Resolution: Fixed > Make PreparedStatementPart an interface > --- > > Key: TORQUE-341 > URL: https://issues.apache.org/jira/browse/TORQUE-341 > Project: Torque > Issue Type: Sub-task > Components: Runtime >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > To retain information about the query in the created query, > PreparedStatementPart should be made an interface. > The current implementation of PreparedStatementPart should be moved to > org.apache.torque.criteria.PreparedStatementPartImpl -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-334) retrieveByPKs(simpleType) should also be generated
[ https://issues.apache.org/jira/browse/TORQUE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-334. --- Resolution: Fixed Fix Version/s: 4.1 solution (thanks to Greg Monroe for the suggestion): - Generate new methods retrieveByTypedPKs and retrieveByObjectKeys. - Made generated methods retrieveByPKs deprecated. - Inserted generation option torque.om.retrieve.bypk.deprecated = true for disabling the generation of the deprecated methods > retrieveByPKs(simpleType) should also be generated > -- > > Key: TORQUE-334 > URL: https://issues.apache.org/jira/browse/TORQUE-334 > Project: Torque > Issue Type: Bug >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > Currently, there is a retrieveByPKs(Collection) method. > But if e.g. the PK is of type Integer, there should also be a > retriveByPKs(Collection) method -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-338) Fix the saving of checksums when runOnlyOnSourceChange is set to true
[
https://issues.apache.org/jira/browse/TORQUE-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox resolved TORQUE-338.
---
Resolution: Fixed
Assignee: Thomas Fox
Fix Version/s: 4.1
Thanks, patch was applied.
> Fix the saving of checksums when runOnlyOnSourceChange is set to true
> -
>
> Key: TORQUE-338
> URL: https://issues.apache.org/jira/browse/TORQUE-338
> Project: Torque
> Issue Type: Bug
> Components: Generator
>Affects Versions: 4.1
>Reporter: Helge Weissig
>Assignee: Thomas Fox
> Fix For: 4.1
>
>
> The generator's Controller loops over a list of UnitDescriptors, each of
> which may have set the option to run only on a source change. Currently, the
> cached checksum file is overwritten by each successive call to
> processGenerationUnit(ControllerState, UnitConfiguration) resulting in only
> the last UnitDescriptor to be skipped on a subsequent run. The following
> patch to Checksums addresses this issue:
> {code}
> Index:
> torque-generator/src/main/java/org/apache/torque/generator/control/Checksums.java
> ===
> ---
> torque-generator/src/main/java/org/apache/torque/generator/control/Checksums.java
> (revision 1689921)
> +++
> torque-generator/src/main/java/org/apache/torque/generator/control/Checksums.java
> (working copy)
> @@ -128,6 +128,29 @@
> Set keys = new HashSet();
> keys.addAll(checksums.keySet());
> keys.addAll(modificationDates.keySet());
> +
> +Checksums existing = new Checksums();
> +existing.readFromFile(toWriteTo);
> +for (String key : existing.getChecksums().keySet())
> +{
> +if (keys.add(key))
> +{
> +checksums.put(key, existing.getChecksum(key));
> +if (existing.getModificationDate(key) != null)
> +{
> +modificationDates.put(key,
> existing.getModificationDate(key));
> +}
> +}
> +}
> +
> +for (String key : existing.getModificationDates().keySet())
> +{
> +if (keys.add(key))
> +{
> +modificationDates.put(key,
> existing.getModificationDate(key));
> +}
> +}
> +
> StringBuilder content = new StringBuilder();
> for (String key : keys)
> {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-338) Fix the saving of checksums when runOnlyOnSourceChange is set to true
[
https://issues.apache.org/jira/browse/TORQUE-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14900055#comment-14900055
]
Thomas Fox commented on TORQUE-338:
---
The problem is that e.g. with maven, by default, the same cache dir is used for
each generation unit
> Fix the saving of checksums when runOnlyOnSourceChange is set to true
> -
>
> Key: TORQUE-338
> URL: https://issues.apache.org/jira/browse/TORQUE-338
> Project: Torque
> Issue Type: Bug
> Components: Generator
>Affects Versions: 4.1
>Reporter: Helge Weissig
>
> The generator's Controller loops over a list of UnitDescriptors, each of
> which may have set the option to run only on a source change. Currently, the
> cached checksum file is overwritten by each successive call to
> processGenerationUnit(ControllerState, UnitConfiguration) resulting in only
> the last UnitDescriptor to be skipped on a subsequent run. The following
> patch to Checksums addresses this issue:
> {code}
> Index:
> torque-generator/src/main/java/org/apache/torque/generator/control/Checksums.java
> ===
> ---
> torque-generator/src/main/java/org/apache/torque/generator/control/Checksums.java
> (revision 1689921)
> +++
> torque-generator/src/main/java/org/apache/torque/generator/control/Checksums.java
> (working copy)
> @@ -128,6 +128,29 @@
> Set keys = new HashSet();
> keys.addAll(checksums.keySet());
> keys.addAll(modificationDates.keySet());
> +
> +Checksums existing = new Checksums();
> +existing.readFromFile(toWriteTo);
> +for (String key : existing.getChecksums().keySet())
> +{
> +if (keys.add(key))
> +{
> +checksums.put(key, existing.getChecksum(key));
> +if (existing.getModificationDate(key) != null)
> +{
> +modificationDates.put(key,
> existing.getModificationDate(key));
> +}
> +}
> +}
> +
> +for (String key : existing.getModificationDates().keySet())
> +{
> +if (keys.add(key))
> +{
> +modificationDates.put(key,
> existing.getModificationDate(key));
> +}
> +}
> +
> StringBuilder content = new StringBuilder();
> for (String key : keys)
> {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-334) retrieveByPKs(simpleType) should also be generated
[ https://issues.apache.org/jira/browse/TORQUE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox reassigned TORQUE-334: - Assignee: Thomas Fox > retrieveByPKs(simpleType) should also be generated > -- > > Key: TORQUE-334 > URL: https://issues.apache.org/jira/browse/TORQUE-334 > Project: Torque > Issue Type: Bug >Reporter: Thomas Fox >Assignee: Thomas Fox > > Currently, there is a retrieveByPKs(Collection) method. > But if e.g. the PK is of type Integer, there should also be a > retriveByPKs(Collection) method -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-334) retrieveByPKs(simpleType) should also be generated
[ https://issues.apache.org/jira/browse/TORQUE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14877319#comment-14877319 ] Thomas Fox commented on TORQUE-334: --- An alternative would be to change the name of the existing methods to "retrieveByObjectKeys" > retrieveByPKs(simpleType) should also be generated > -- > > Key: TORQUE-334 > URL: https://issues.apache.org/jira/browse/TORQUE-334 > Project: Torque > Issue Type: Bug >Reporter: Thomas Fox > > Currently, there is a retrieveByPKs(Collection) method. > But if e.g. the PK is of type Integer, there should also be a > retriveByPKs(Collection) method -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-334) retrieveByPKs(simpleType) should also be generated
[ https://issues.apache.org/jira/browse/TORQUE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14877312#comment-14877312 ] Thomas Fox commented on TORQUE-334: --- A different name must be used for the new method as it would have the same erasure as retrieveByPKs(Collection) > retrieveByPKs(simpleType) should also be generated > -- > > Key: TORQUE-334 > URL: https://issues.apache.org/jira/browse/TORQUE-334 > Project: Torque > Issue Type: Bug >Reporter: Thomas Fox > > Currently, there is a retrieveByPKs(Collection) method. > But if e.g. the PK is of type Integer, there should also be a > retriveByPKs(Collection) method -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Updated] (TORQUE-334) retrieveByPKs(simpleType) should also be generated
[ https://issues.apache.org/jira/browse/TORQUE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox updated TORQUE-334: -- Description: Currently, there is a retrieveByPKs(Collection) method. But if e.g. the PK is of type Integer, there should also be a retriveByPKs(Collection) method was: Currently, there is a retriveByPKs(Collection>ObjectKey) method. But if e.g. the PK is of type Integer, there should also be a retriveByPKs(Collection) method > retrieveByPKs(simpleType) should also be generated > -- > > Key: TORQUE-334 > URL: https://issues.apache.org/jira/browse/TORQUE-334 > Project: Torque > Issue Type: Bug >Reporter: Thomas Fox > > Currently, there is a retrieveByPKs(Collection) method. > But if e.g. the PK is of type Integer, there should also be a > retriveByPKs(Collection) method -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Updated] (TORQUE-334) retrieveByPKs(simpleType) should also be generated
[ https://issues.apache.org/jira/browse/TORQUE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox updated TORQUE-334: -- Description: Currently, there is a retriveByPKs(Collection>ObjectKey) method. But if e.g. the PK is of type Integer, there should also be a retriveByPKs(Collection) method was: Currently, there is a retriveByPKs(Collection>ObjectKey) method. But if e.g. the PK is of type Integer, there should also be a retriveByPKs(Collection>Integer) method > retrieveByPKs(simpleType) should also be generated > -- > > Key: TORQUE-334 > URL: https://issues.apache.org/jira/browse/TORQUE-334 > Project: Torque > Issue Type: Bug >Reporter: Thomas Fox > > Currently, there is a retriveByPKs(Collection>ObjectKey) method. > But if e.g. the PK is of type Integer, there should also be a > retriveByPKs(Collection) method -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-226) The existing target mode "merge" has problems with files without line break at end of file
[ https://issues.apache.org/jira/browse/TORQUE-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-226. --- Resolution: Fixed Fix Version/s: 4.1 > The existing target mode "merge" has problems with files without line break > at end of file > -- > > Key: TORQUE-226 > URL: https://issues.apache.org/jira/browse/TORQUE-226 > Project: Torque > Issue Type: Bug > Components: Generator >Affects Versions: 4.0-beta1 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > A file is generated with existingTargetStrategy="merge". The generated file > does exist neither in the raw-generated directory nor in its target. > Observer behaviour: The generated file has the last line duplicated a few > times. > Expected behaviour: The generated file should contain the last line only once. > Note: the raw-generated file is ok, the problem only occurs in the merged > file. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-226) The existing target mode "merge" has problems with files without line break at end of file
[ https://issues.apache.org/jira/browse/TORQUE-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14877288#comment-14877288 ] Thomas Fox commented on TORQUE-226: --- We proceed by using the new jgit version and upgrading to jdk 1.7 > The existing target mode "merge" has problems with files without line break > at end of file > -- > > Key: TORQUE-226 > URL: https://issues.apache.org/jira/browse/TORQUE-226 > Project: Torque > Issue Type: Bug > Components: Generator >Affects Versions: 4.0-beta1 >Reporter: Thomas Fox >Assignee: Thomas Fox > > A file is generated with existingTargetStrategy="merge". The generated file > does exist neither in the raw-generated directory nor in its target. > Observer behaviour: The generated file has the last line duplicated a few > times. > Expected behaviour: The generated file should contain the last line only once. > Note: the raw-generated file is ok, the problem only occurs in the merged > file. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-327) Upgrade to JCS-2.0
[ https://issues.apache.org/jira/browse/TORQUE-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-327. --- Resolution: Fixed > Upgrade to JCS-2.0 > --- > > Key: TORQUE-327 > URL: https://issues.apache.org/jira/browse/TORQUE-327 > Project: Torque > Issue Type: New Feature > Components: Runtime >Affects Versions: 4.1 >Reporter: Youngho Cho >Assignee: Thomas Vandahl > > Currently Torque runtime use JCS-1.3. > But JCS-1.3 is very old and not support useful new java feature likes nio, > generics etc. > I think it time to migrate official Torque runtime JCS library upgrade to > JCS-2.0. > As you know, JCS-2.0 removed old concurrent package dependency and use NIO > for disk cache and add new features. > Thanks, > Youngho -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Updated] (TORQUE-327) Upgrade to JCS-2.0
[ https://issues.apache.org/jira/browse/TORQUE-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox updated TORQUE-327: -- Fix Version/s: 4.1 > Upgrade to JCS-2.0 > --- > > Key: TORQUE-327 > URL: https://issues.apache.org/jira/browse/TORQUE-327 > Project: Torque > Issue Type: New Feature > Components: Runtime >Affects Versions: 4.1 >Reporter: Youngho Cho >Assignee: Thomas Vandahl > Fix For: 4.1 > > > Currently Torque runtime use JCS-1.3. > But JCS-1.3 is very old and not support useful new java feature likes nio, > generics etc. > I think it time to migrate official Torque runtime JCS library upgrade to > JCS-2.0. > As you know, JCS-2.0 removed old concurrent package dependency and use NIO > for disk cache and add new features. > Thanks, > Youngho -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-327) Upgrade to JCS-2.0
[ https://issues.apache.org/jira/browse/TORQUE-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox reassigned TORQUE-327: - Assignee: Thomas Vandahl > Upgrade to JCS-2.0 > --- > > Key: TORQUE-327 > URL: https://issues.apache.org/jira/browse/TORQUE-327 > Project: Torque > Issue Type: New Feature > Components: Runtime >Affects Versions: 4.1 >Reporter: Youngho Cho >Assignee: Thomas Vandahl > > Currently Torque runtime use JCS-1.3. > But JCS-1.3 is very old and not support useful new java feature likes nio, > generics etc. > I think it time to migrate official Torque runtime JCS library upgrade to > JCS-2.0. > As you know, JCS-2.0 removed old concurrent package dependency and use NIO > for disk cache and add new features. > Thanks, > Youngho -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-339) Correct the order of outlet and mergepoint in the last example of the configuration section of the code generation documentation
[
https://issues.apache.org/jira/browse/TORQUE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox resolved TORQUE-339.
---
Resolution: Fixed
Assignee: (was: Thomas Fox)
Fix Version/s: 4.1
> Correct the order of outlet and mergepoint in the last example of the
> configuration section of the code generation documentation
>
>
> Key: TORQUE-339
> URL: https://issues.apache.org/jira/browse/TORQUE-339
> Project: Torque
> Issue Type: Bug
> Components: Documentation
>Reporter: Helge Weissig
> Fix For: 4.1
>
>
> When overriding a single mergepoint, the outlet must be listed first
> according to the schema definition. The following patch addresses that:
> {code}
> Index:
> torque-site/src/site/xdoc/documentation/codegen-reference/configuration.xml
> ===
> ---
> torque-site/src/site/xdoc/documentation/codegen-reference/configuration.xml
> (revision 1689921)
> +++
> torque-site/src/site/xdoc/documentation/codegen-reference/configuration.xml
> (working copy)
> @@ -294,14 +294,14 @@
> http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://db.apache.org/torque/4.0/generator/configuration
> http://db.apache.org/torque/4.0/generator/configuration.xsd";
> xmlns="http://db.apache.org/torque/4.0/generator/configuration";>
> -
> -
> -
> -
>xsi:type="velocityOutlet"
>path="bean/base/setter2.vm">
>
> +
> +
> +
> +
>
> ]]>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-339) Correct the order of outlet and mergepoint in the last example of the configuration section of the code generation documentation
[
https://issues.apache.org/jira/browse/TORQUE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox reassigned TORQUE-339:
-
Assignee: Thomas Fox
> Correct the order of outlet and mergepoint in the last example of the
> configuration section of the code generation documentation
>
>
> Key: TORQUE-339
> URL: https://issues.apache.org/jira/browse/TORQUE-339
> Project: Torque
> Issue Type: Bug
> Components: Documentation
>Reporter: Helge Weissig
>Assignee: Thomas Fox
> Fix For: 4.1
>
>
> When overriding a single mergepoint, the outlet must be listed first
> according to the schema definition. The following patch addresses that:
> {code}
> Index:
> torque-site/src/site/xdoc/documentation/codegen-reference/configuration.xml
> ===
> ---
> torque-site/src/site/xdoc/documentation/codegen-reference/configuration.xml
> (revision 1689921)
> +++
> torque-site/src/site/xdoc/documentation/codegen-reference/configuration.xml
> (working copy)
> @@ -294,14 +294,14 @@
> http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://db.apache.org/torque/4.0/generator/configuration
> http://db.apache.org/torque/4.0/generator/configuration.xsd";
> xmlns="http://db.apache.org/torque/4.0/generator/configuration";>
> -
> -
> -
> -
>xsi:type="velocityOutlet"
>path="bean/base/setter2.vm">
>
> +
> +
> +
> +
>
> ]]>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-306) Use named variables for replacements
[ https://issues.apache.org/jira/browse/TORQUE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-306. --- Resolution: Fixed Fix Version/s: 4.1 > Use named variables for replacements > > > Key: TORQUE-306 > URL: https://issues.apache.org/jira/browse/TORQUE-306 > Project: Torque > Issue Type: Improvement > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Fox > Fix For: 4.1 > > > Currently, replacement values are addressed by their position in the > replacement values list. If users are forced to create statements by hand, > this is rather error-prone and not very useable. > It would be nice if an additional mechanism could be implemented by using > named replacement parameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-226) The existing target mode "merge" has problems with files without line break at end of file
[ https://issues.apache.org/jira/browse/TORQUE-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14731691#comment-14731691 ] Thomas Fox commented on TORQUE-226: --- This is fixed in jgit version 4.0.1.201506240215-r However, this version of jgit needs jdk 1.7 Will ask at the dev list whether it is ok to change the required jdk version of the generator to 1.7 > The existing target mode "merge" has problems with files without line break > at end of file > -- > > Key: TORQUE-226 > URL: https://issues.apache.org/jira/browse/TORQUE-226 > Project: Torque > Issue Type: Bug > Components: Generator >Affects Versions: 4.0-beta1 >Reporter: Thomas Fox >Assignee: Thomas Fox > > A file is generated with existingTargetStrategy="merge". The generated file > does exist neither in the raw-generated directory nor in its target. > Observer behaviour: The generated file has the last line duplicated a few > times. > Expected behaviour: The generated file should contain the last line only once. > Note: the raw-generated file is ok, the problem only occurs in the merged > file. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-203) Quote table names in creation
[ https://issues.apache.org/jira/browse/TORQUE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-203. --- Resolution: Won't Fix Resolved as won't fix as no workable solution has come up. Please reopen if there are feasible ideas of how to alert the user that a reserved word is used as table or column names. > Quote table names in creation > - > > Key: TORQUE-203 > URL: https://issues.apache.org/jira/browse/TORQUE-203 > Project: Torque > Issue Type: Improvement >Reporter: Thomas Fox > > For some databases, table names can be quoted in the sql create scripts to > avoid collisions with predefined names. Where possible, such quotation should > be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-108) Criteria addJoin causes incorrect SQL to be generated when optional schema references are in use (Oracle)
[ https://issues.apache.org/jira/browse/TORQUE-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617843#comment-14617843 ] Thomas Fox commented on TORQUE-108: --- This problem is fixed in 4.0. I am not sure whether the attached patch was used for the fix, so no idea whether it is working to patch 3.3 or not. > Criteria addJoin causes incorrect SQL to be generated when optional schema > references are in use (Oracle) > - > > Key: TORQUE-108 > URL: https://issues.apache.org/jira/browse/TORQUE-108 > Project: Torque > Issue Type: Bug > Components: Runtime >Affects Versions: 3.3-RC1, 3.3-RC2, 3.3-RC3 > Environment: Linux, Java 1.6 >Reporter: Brendan Miller >Assignee: Thomas Fox > Fix For: 4.0-beta1 > > Attachments: JoinBuilderTest.java, joinbuilder.patch > > > I previously wrote about this to torque-user in Oct 2007. > In a schema definition that includes torque.dsfactory.programs.schema, > writing the following > Criteria crit = new Criteria(); > crit.addJoin(TransactionPeer.ORDER_ID, OrderPeer.ID); > crit.add(TransactionPeer.ACCT_ID, account.getID()); > List orders = OrderPeer.doSelect(crit); > generates > SELECT <..ORDERS columns..> FROM TRANSACTION, ORDERS, DBSCHEMA.ORDERS, > DBSCHEMA.TRANSACTION > WHERE TRANSACTION.ORDER_ID=ORDERS.ID AND TRANSACTION.ACCT_ID= ? > Upon examining the Torque code, it appears that SQLBuilder.processJoins does > not add the full table names, while SQLBuilder.processCriterions does. > Shouldn't they both add the full table names? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-336) Incorrect schema location in documentation and database-4-0-strict.xsd
[ https://issues.apache.org/jira/browse/TORQUE-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-336. --- Resolution: Fixed Fix Version/s: 4.1 > Incorrect schema location in documentation and database-4-0-strict.xsd > -- > > Key: TORQUE-336 > URL: https://issues.apache.org/jira/browse/TORQUE-336 > Project: Torque > Issue Type: Bug > Components: Generator >Affects Versions: 4.0 >Reporter: Helge Weissig > Fix For: 4.1 > > > The schema location in the documentation and in the correct "strict" schema > (available now at > http://db.apache.org/torque/torque-4.0/documentation/orm-reference/database-4-0-strict.xsd) > still reference http://db.apache.org/torque/4.0/templates/database.xsd -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-334) retrieveByPKs(simpleType) should also be generated
Thomas Fox created TORQUE-334: - Summary: retrieveByPKs(simpleType) should also be generated Key: TORQUE-334 URL: https://issues.apache.org/jira/browse/TORQUE-334 Project: Torque Issue Type: Bug Reporter: Thomas Fox Currently, there is a retriveByPKs(Collection>ObjectKey) method. But if e.g. the PK is of type Integer, there should also be a retriveByPKs(Collection>Integer) method -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-269) Offline docs do not contain xsd files
[ https://issues.apache.org/jira/browse/TORQUE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-269. --- Resolution: Fixed Fix Version/s: 4.1 Assignee: Thomas Fox > Offline docs do not contain xsd files > - > > Key: TORQUE-269 > URL: https://issues.apache.org/jira/browse/TORQUE-269 > Project: Torque > Issue Type: Bug > Components: Documentation >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-290) Improve building from clause in subselect
[
https://issues.apache.org/jira/browse/TORQUE-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184484#comment-14184484
]
Thomas Fox commented on TORQUE-290:
---
There are two strategies to address the problem:
1) remove the unwanted table in the inner from clause when composing the
original query
2) remove the unwanted table in the inner from clause after compoing the
original query
1) has the problem that the from clause of the outer query has to be known when
creating the inner query. Currently, the query creation is from the inner query
to the outer query. This would change lots of the query creation code and would
improve its comlexity significantly.
2) is also problematic because the inner query is created to a string quite
early, and all status information is lost.
The information flow when creating the query is as follows
In the case that the subselect is in the where clause:
The information starts as FromElement in the Criteria.topLevelCriterion
then gets converted into a PreparedStatementPart in
org.apache.torque.sql.objectbuilder.ObjectOrColumnPsPartBuilder.buildPs(Object,
boolean, Adapter)
then gets appended to Query.whereClause (StringBuilder) in
org.apache.torque.sql.SqlBuilder.appendCriterion(Criterion, Criteria,
StringBuilder, Query)
So one would have to adjust FromElement, PreparedStatementPart and
query.whereClause to be able to postprocess the query.
This is also quite a big change.
> Improve building from clause in subselect
> -
>
> Key: TORQUE-290
> URL: https://issues.apache.org/jira/browse/TORQUE-290
> Project: Torque
> Issue Type: Improvement
> Components: Runtime
>Affects Versions: 4.0
>Reporter: Thomas Fox
>Assignee: Thomas Fox
> Labels: incompatibleChange
>
> Currently, it is not easily possible to reference columns in the main select
> from a subselect.
> For example, to select authors which have published exactly one book, one can
> use the SQL:
> SELECT * FROM author WHERE (SELECT COUNT(*) FROM book WHERE
> book.author_id=author.author_id)=1
> One would like to achieve this by
> Criteria subselect = new Criteria();
> subselect.where(BookPeer.AUTHOR_ID, AuthorPeer.AUTHOR_ID);
> subselect.addSelectColumn(new Count("*"));
> Criteria criteria = new Criteria();
> criteria.where(subselect, 1);
> List result = AuthorPeer.doSelect(criteria);
> but the SQL results in (note the additional author in the from clause of the
> subselect)
> SELECT * FROM author WHERE (SELECT COUNT(*) FROM book, author WHERE
> book.author_id=author.author_id)=1
> So the desired behavior is:
> If a table also exists in the from clause of the outer criteria, it should
> not be added to the from clause of the subselect
> NOTE1: This change can change the behaviour of Torque in existing code
> NOTE2: Workarounds exist, e.g. defining the FROM clause of the subselect
> manually using Criteria.addFrom() or using "new
> ColumnImpl(null,null,null,AuthorPeer.AUTHOR_ID.getSqlExpression())" as join
> column in the WHERE clause of the subselect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-333) Criteria.addJoin(PreparedStatementPart, PreparedStatementPart, Criterion, JoinTpye) discards replacements
[ https://issues.apache.org/jira/browse/TORQUE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-333. --- Resolution: Fixed > Criteria.addJoin(PreparedStatementPart, PreparedStatementPart, Criterion, > JoinTpye) discards replacements > -- > > Key: TORQUE-333 > URL: https://issues.apache.org/jira/browse/TORQUE-333 > Project: Torque > Issue Type: Bug > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > The preparedStatementReplacements in the second PreparedStatementPart > arguments are not copied to the final query as they should, but are ommitted. > This results in incorrect SQL. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-333) Criteria.addJoin(PreparedStatementPart, PreparedStatementPart, Criterion, JoinTpye) discards replacements
Thomas Fox created TORQUE-333: - Summary: Criteria.addJoin(PreparedStatementPart, PreparedStatementPart, Criterion, JoinTpye) discards replacements Key: TORQUE-333 URL: https://issues.apache.org/jira/browse/TORQUE-333 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 4.0 Reporter: Thomas Fox Assignee: Thomas Fox Fix For: 4.1 The preparedStatementReplacements in the second PreparedStatementPart arguments are not copied to the final query as they should, but are ommitted. This results in incorrect SQL. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Updated] (TORQUE-290) Improve building from clause in subselect
[
https://issues.apache.org/jira/browse/TORQUE-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox updated TORQUE-290:
--
Description:
Currently, it is not easily possible to reference columns in the main select
from a subselect.
For example, to select authors which have published exactly one book, one can
use the SQL:
SELECT * FROM author WHERE (SELECT COUNT(*) FROM book WHERE
book.author_id=author.author_id)=1
One would like to achieve this by
Criteria subselect = new Criteria();
subselect.where(BookPeer.AUTHOR_ID, AuthorPeer.AUTHOR_ID);
subselect.addSelectColumn(new Count("*"));
Criteria criteria = new Criteria();
criteria.where(subselect, 1);
List result = AuthorPeer.doSelect(criteria);
but the SQL results in (note the additional author in the from clause of the
subselect)
SELECT * FROM author WHERE (SELECT COUNT(*) FROM book, author WHERE
book.author_id=author.author_id)=1
So the desired behavior is:
If a table also exists in the from clause of the outer criteria, it should not
be added to the from clause of the subselect
NOTE1: This change can change the behaviour of Torque in existing code
NOTE2: Workarounds exist, e.g. defining the FROM clause of the subselect
manually using Criteria.addFrom() or using "new
ColumnImpl(null,null,null,AuthorPeer.AUTHOR_ID.getSqlExpression())" as join
column in the WHERE clause of the subselect.
was:
Currently, it is not easily possible to reference columns in the main select
from a subselect.
For example:
Select authors which have published more than three books
SELECT * FROM author WHERE (SELECT COUNT(*) FROM book WHERE
book.author_id=author.author_id)=1
One would like to achieve this by
Criteria subselect = new Criteria();
subselect.where(BookPeer.AUTHOR_ID, AuthorPeer.AUTHOR_ID);
subselect.addSelectColumn(new Count("*"));
Criteria criteria = new Criteria();
criteria.where(subselect, 1);
List result = AuthorPeer.doSelect(criteria);
but the SQL results in (note the additional author in the from clause of the
subselect)
SELECT * FROM author WHERE (SELECT COUNT(*) FROM book, author WHERE
book.author_id=author.author_id)=1
So the desired behavior is:
If a table also exists in the from clause of the outer criteria, it should not
be added to the from clause of the subselect
NOTE1: This change can change the behaviour of Torque in existing code
NOTE2: Workarounds exist, e.g. defining the FROM clause of the subselect
manually using Criteria.addFrom() or using "new
ColumnImpl(null,null,null,AuthorPeer.AUTHOR_ID.getSqlExpression())" as join
column in the WHERE clause of the subselect.
> Improve building from clause in subselect
> -
>
> Key: TORQUE-290
> URL: https://issues.apache.org/jira/browse/TORQUE-290
> Project: Torque
> Issue Type: Improvement
> Components: Runtime
>Affects Versions: 4.0
>Reporter: Thomas Fox
>Assignee: Thomas Fox
> Labels: incompatibleChange
>
> Currently, it is not easily possible to reference columns in the main select
> from a subselect.
> For example, to select authors which have published exactly one book, one can
> use the SQL:
> SELECT * FROM author WHERE (SELECT COUNT(*) FROM book WHERE
> book.author_id=author.author_id)=1
> One would like to achieve this by
> Criteria subselect = new Criteria();
> subselect.where(BookPeer.AUTHOR_ID, AuthorPeer.AUTHOR_ID);
> subselect.addSelectColumn(new Count("*"));
> Criteria criteria = new Criteria();
> criteria.where(subselect, 1);
> List result = AuthorPeer.doSelect(criteria);
> but the SQL results in (note the additional author in the from clause of the
> subselect)
> SELECT * FROM author WHERE (SELECT COUNT(*) FROM book, author WHERE
> book.author_id=author.author_id)=1
> So the desired behavior is:
> If a table also exists in the from clause of the outer criteria, it should
> not be added to the from clause of the subselect
> NOTE1: This change can change the behaviour of Torque in existing code
> NOTE2: Workarounds exist, e.g. defining the FROM clause of the subselect
> manually using Criteria.addFrom() or using "new
> ColumnImpl(null,null,null,AuthorPeer.AUTHOR_ID.getSqlExpression())" as join
> column in the WHERE clause of the subselect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-332) Criteria.addJoin(String, String, Criterion, JoinType) does not honor default schema
[ https://issues.apache.org/jira/browse/TORQUE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-332. --- Resolution: Fixed > Criteria.addJoin(String, String, Criterion, JoinType) does not honor default > schema > --- > > Key: TORQUE-332 > URL: https://issues.apache.org/jira/browse/TORQUE-332 > Project: Torque > Issue Type: Bug > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > Situation: A Default schema is set in Torque, i.e. all Table names should be > prefixed with a schema name. > A Criteria is created, using the Criteria.addJoin(String, String, Criterion, > JoinType) method, where at least one of the Strings is an unqualified table > name. > Current behaviour: The unqualified table names are retained in the SQL > created from the criteria. > Desired behaviour: The unqualified table names should be prefixed with the > schema prefix -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Updated] (TORQUE-332) Criteria.addJoin(String, String, Criterion, JoinType) does not honor default schema
[ https://issues.apache.org/jira/browse/TORQUE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox updated TORQUE-332: -- Description: Situation: A Default schema is set in Torque, i.e. all Table names should be prefixed with a schema name. A Criteria is created, using the Criteria.addJoin(String, String, Criterion, JoinType) method, where at least one of the Strings is an unqualified table name. Current behaviour: The unqualified table names are retained in the SQL created from the criteria. Desired behaviour: The unqualified table names should be prefixed with the schema prefix was: Situation: A Default schema is set in Torque, i.e. all Table names should be prefixed with a schema name. A Criteria is created, using the Criteria.addJoin(String, String, Criteria), where at least one of the Strings is an unqualified table name. Current behaviour: The unqualified table names are retained in the SQL created from the criteria. Desired behaviour: The unqualified table names should be prefixed with the schema prefix > Criteria.addJoin(String, String, Criterion, JoinType) does not honor default > schema > --- > > Key: TORQUE-332 > URL: https://issues.apache.org/jira/browse/TORQUE-332 > Project: Torque > Issue Type: Bug > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > Situation: A Default schema is set in Torque, i.e. all Table names should be > prefixed with a schema name. > A Criteria is created, using the Criteria.addJoin(String, String, Criterion, > JoinType) method, where at least one of the Strings is an unqualified table > name. > Current behaviour: The unqualified table names are retained in the SQL > created from the criteria. > Desired behaviour: The unqualified table names should be prefixed with the > schema prefix -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Updated] (TORQUE-332) Criteria.addJoin(String, String, Criterion, JoinType) does not honor default schema
[ https://issues.apache.org/jira/browse/TORQUE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox updated TORQUE-332: -- Summary: Criteria.addJoin(String, String, Criterion, JoinType) does not honor default schema (was: Criteria.addJoin(String, String, Criteria) does not honor default schema) > Criteria.addJoin(String, String, Criterion, JoinType) does not honor default > schema > --- > > Key: TORQUE-332 > URL: https://issues.apache.org/jira/browse/TORQUE-332 > Project: Torque > Issue Type: Bug > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > Situation: A Default schema is set in Torque, i.e. all Table names should be > prefixed with a schema name. > A Criteria is created, using the Criteria.addJoin(String, String, Criteria), > where at least one of the Strings is an unqualified table name. > Current behaviour: The unqualified table names are retained in the SQL > created from the criteria. > Desired behaviour: The unqualified table names should be prefixed with the > schema prefix -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-331) Make enum generation possible
[
https://issues.apache.org/jira/browse/TORQUE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184375#comment-14184375
]
Thomas Fox commented on TORQUE-331:
---
For being able to use enum values in select like
Criteria criteria = new Criteria()
.where(new ColumnImpl("table.column1"), EnumWithValueMethod.A)
.and(EnumWithValueMethod.B, new ColumnImpl("table.column2"))
I tried to define the interface ValueHolder (see below) to check whether an
argument is an enum and needs to be converted to its inner value.
However, as generation also depends on the static method getByValue() which
cannot be defined in an interface,
and to let torque user be more free when defining custom enums, I did not
commit the interface code.
Instead, now the SqlBuilder checks whether an argument is an enum, and if yes,
it is required that the enum has a parameterless getValue() method which is
called to convert the enum into a SQL value, see
org.apache.torque.sql.whereclausebuilder.EnumValueBuilder.
P.S code for the ValueHolder interface:
/**
* An interface for an object that has an inner SQLvalue.
* The value object can be retrieved using the getValue() method.
* It is also required that there exists a static method
* getByValue(T value), which returns a ValueHolder object for
* a specific value. The existence of this method cannot be enforced
* by this interface but it is required nonetheless by Torque.
*
* @param the class of the internal value.
*/
public interface ValueHolder
{
/**
* Returns the SQL value represented by this instance.
*
* @return the represented value, not null.
*/
T getValue();
// Returns a ValueHolder object for a specific value.
// @param value the value to return the ValueHolder object for.
// @return the ValueHolder object, only null if value was null.
//
// static ValueHolder getByValue(T value);
}
> Make enum generation possible
> -
>
> Key: TORQUE-331
> URL: https://issues.apache.org/jira/browse/TORQUE-331
> Project: Torque
> Issue Type: New Feature
> Components: Templates
>Affects Versions: 4.0
>Reporter: Thomas Fox
>Assignee: Thomas Fox
> Fix For: 4.1
>
>
> It should be possible to generate an enum for a value.
> In the schema, this would look like
>
>
>
> There should be an optional javaName Attribute for the enum-value element
> determining the java name for the enum value.
> There should be an optional description Attribute for the enum-value element
> determining the javadoc for the enum value.
> There should be an optional enumName Attribute for the column element
> determining the type name for the enum. Its value can be either fully
> qualified or unqualified to create a new enum.
> If there are enum-value elements present, the enum type should be generated,
> otherwise, it is assumed to exist already and is not generated.
> The data object getters and setters signatures would then be
> public RoleEnum getRole();
> private void setRole(RoleEnum role);
> The generated enum like would look like
> public enum RoleEnum
> {
> ADMIN("Admin"),
> USER("User");
> private String value;
> private RoleEnum(String value) {...}
> private Sting getValue() {...}
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-331) Make enum generation possible
[
https://issues.apache.org/jira/browse/TORQUE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox resolved TORQUE-331.
---
Resolution: Fixed
> Make enum generation possible
> -
>
> Key: TORQUE-331
> URL: https://issues.apache.org/jira/browse/TORQUE-331
> Project: Torque
> Issue Type: New Feature
> Components: Templates
>Affects Versions: 4.0
>Reporter: Thomas Fox
>Assignee: Thomas Fox
> Fix For: 4.1
>
>
> It should be possible to generate an enum for a value.
> In the schema, this would look like
>
>
>
> There should be an optional javaName Attribute for the enum-value element
> determining the java name for the enum value.
> There should be an optional description Attribute for the enum-value element
> determining the javadoc for the enum value.
> There should be an optional enumName Attribute for the column element
> determining the type name for the enum. Its value can be either fully
> qualified or unqualified to create a new enum.
> If there are enum-value elements present, the enum type should be generated,
> otherwise, it is assumed to exist already and is not generated.
> The data object getters and setters signatures would then be
> public RoleEnum getRole();
> private void setRole(RoleEnum role);
> The generated enum like would look like
> public enum RoleEnum
> {
> ADMIN("Admin"),
> USER("User");
> private String value;
> private RoleEnum(String value) {...}
> private Sting getValue() {...}
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-332) Criteria.addJoin(String, String, Criteria) does not honor default schema
Thomas Fox created TORQUE-332: - Summary: Criteria.addJoin(String, String, Criteria) does not honor default schema Key: TORQUE-332 URL: https://issues.apache.org/jira/browse/TORQUE-332 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 4.0 Reporter: Thomas Fox Assignee: Thomas Fox Fix For: 4.1 Situation: A Default schema is set in Torque, i.e. all Table names should be prefixed with a schema name. A Criteria is created, using the Criteria.addJoin(String, String, Criteria), where at least one of the Strings is an unqualified table name. Current behaviour: The unqualified table names are retained in the SQL created from the criteria. Desired behaviour: The unqualified table names should be prefixed with the schema prefix -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Updated] (TORQUE-331) Make enum generation possible
[
https://issues.apache.org/jira/browse/TORQUE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox updated TORQUE-331:
--
Description:
It should be possible to generate an enum for a value.
In the schema, this would look like
There should be an optional javaName Attribute for the enum-value element
determining the java name for the enum value.
There should be an optional description Attribute for the enum-value element
determining the javadoc for the enum value.
There should be an optional enumName Attribute for the column element
determining the type name for the enum. Its value can be either fully qualified
or unqualified to create a new enum.
If there are enum-value elements present, the enum type should be generated,
otherwise, it is assumed to exist already and is not generated.
The data object getters and setters signatures would then be
public RoleEnum getRole();
private void setRole(RoleEnum role);
The generated enum like would look like
public enum RoleEnum
{
ADMIN("Admin"),
USER("User");
private String value;
private RoleEnum(String value) {...}
private Sting getValue() {...}
}
was:
It should be possible to generate an enum for a value.
In the schema, this would look like
There should be an optional javaName Attribute for the enumValue element
determining the java name for the enum value.
There should be an optional description Attribute for the enumValue element
determining the javadoc for the enum value.
There should be an optional enumName Attribute for the column element
determining the type name for the enum. Its value can be either fully qualified
or unqualified to create a new enum.
If there are enumValue elements present, the enum type should be generated,
otherwise, it is assumed to exist already and is not generated.
The data object getters and setters signatures would then be
public RoleEnum getRole();
private void setRole(RoleEnum role);
The generated enum like would look like
public enum RoleEnum
{
ADMIN("Admin"),
USER("User");
private String value;
private RoleEnum(String value) {...}
private Sting getValue() {...};
}
> Make enum generation possible
> -
>
> Key: TORQUE-331
> URL: https://issues.apache.org/jira/browse/TORQUE-331
> Project: Torque
> Issue Type: New Feature
> Components: Templates
>Affects Versions: 4.0
>Reporter: Thomas Fox
>Assignee: Thomas Fox
> Fix For: 4.1
>
>
> It should be possible to generate an enum for a value.
> In the schema, this would look like
>
>
>
> There should be an optional javaName Attribute for the enum-value element
> determining the java name for the enum value.
> There should be an optional description Attribute for the enum-value element
> determining the javadoc for the enum value.
> There should be an optional enumName Attribute for the column element
> determining the type name for the enum. Its value can be either fully
> qualified or unqualified to create a new enum.
> If there are enum-value elements present, the enum type should be generated,
> otherwise, it is assumed to exist already and is not generated.
> The data object getters and setters signatures would then be
> public RoleEnum getRole();
> private void setRole(RoleEnum role);
> The generated enum like would look like
> public enum RoleEnum
> {
> ADMIN("Admin"),
> USER("User");
> private String value;
> private RoleEnum(String value) {...}
> private Sting getValue() {...}
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-331) Make enum generation possible
[
https://issues.apache.org/jira/browse/TORQUE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165881#comment-14165881
]
Thomas Fox commented on TORQUE-331:
---
If possible, a constraint should be generated on the database to disallow
values other than defined in the enum for the colum.
For example (Oracle):
ALTER TABLE ROLE ADD CONSTRAINT check_role CHECK (role IN ('ADMIN', 'User'));
> Make enum generation possible
> -
>
> Key: TORQUE-331
> URL: https://issues.apache.org/jira/browse/TORQUE-331
> Project: Torque
> Issue Type: New Feature
> Components: Templates
>Affects Versions: 4.0
>Reporter: Thomas Fox
>Assignee: Thomas Fox
> Fix For: 4.1
>
>
> It should be possible to generate an enum for a value.
> In the schema, this would look like
>
>
>
> There should be an optional javaName Attribute for the enumValue element
> determining the java name for the enum value.
> There should be an optional description Attribute for the enumValue element
> determining the javadoc for the enum value.
> There should be an optional enumName Attribute for the column element
> determining the type name for the enum. Its value can be either fully
> qualified or unqualified to create a new enum.
> If there are enumValue elements present, the enum type should be generated,
> otherwise, it is assumed to exist already and is not generated.
> The data object getters and setters signatures would then be
> public RoleEnum getRole();
> private void setRole(RoleEnum role);
> The generated enum like would look like
> public enum RoleEnum
> {
> ADMIN("Admin"),
> USER("User");
> private String value;
> private RoleEnum(String value) {...}
> private Sting getValue() {...};
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-331) Make enum generation possible
Thomas Fox created TORQUE-331:
-
Summary: Make enum generation possible
Key: TORQUE-331
URL: https://issues.apache.org/jira/browse/TORQUE-331
Project: Torque
Issue Type: New Feature
Components: Templates
Affects Versions: 4.0
Reporter: Thomas Fox
Assignee: Thomas Fox
Fix For: 4.1
It should be possible to generate an enum for a value.
In the schema, this would look like
There should be an optional javaName Attribute for the enumValue element
determining the java name for the enum value.
There should be an optional description Attribute for the enumValue element
determining the javadoc for the enum value.
There should be an optional enumName Attribute for the column element
determining the type name for the enum. Its value can be either fully qualified
or unqualified to create a new enum.
If there are enumValue elements present, the enum type should be generated,
otherwise, it is assumed to exist already and is not generated.
The data object getters and setters signatures would then be
public RoleEnum getRole();
private void setRole(RoleEnum role);
The generated enum like would look like
public enum RoleEnum
{
ADMIN("Admin"),
USER("User");
private String value;
private RoleEnum(String value) {...}
private Sting getValue() {...};
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-329) Create better schema documentation
[ https://issues.apache.org/jira/browse/TORQUE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-329. --- Resolution: Fixed Fix Version/s: 4.1 Added a schema reference to the documentation/orm-reference/defining-the-schema page > Create better schema documentation > -- > > Key: TORQUE-329 > URL: https://issues.apache.org/jira/browse/TORQUE-329 > Project: Torque > Issue Type: Improvement > Components: Documentation >Affects Versions: 4.0 >Reporter: Youngho Cho >Assignee: Thomas Fox > Fix For: 4.1 > > > It would be great if a schema-reference document would exist like in > torque-3.3 > https://db.apache.org/torque/torque-3.3/releases/torque-3.3/generator/schema-reference.html -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-329) Create better schema documentation
[ https://issues.apache.org/jira/browse/TORQUE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox reassigned TORQUE-329: - Assignee: Thomas Fox > Create better schema documentation > -- > > Key: TORQUE-329 > URL: https://issues.apache.org/jira/browse/TORQUE-329 > Project: Torque > Issue Type: Improvement > Components: Documentation >Affects Versions: 4.0 >Reporter: Youngho Cho >Assignee: Thomas Fox > > It would be great if a schema-reference document would exist like in > torque-3.3 > https://db.apache.org/torque/torque-3.3/releases/torque-3.3/generator/schema-reference.html -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Updated] (TORQUE-329) Create better schema documentation
[ https://issues.apache.org/jira/browse/TORQUE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox updated TORQUE-329: -- Summary: Create better schema documentation (was: Create better schema documentaion) > Create better schema documentation > -- > > Key: TORQUE-329 > URL: https://issues.apache.org/jira/browse/TORQUE-329 > Project: Torque > Issue Type: Improvement > Components: Documentation >Affects Versions: 4.0 >Reporter: Youngho Cho > > It would be great if a schema-reference document would exist like in > torque-3.3 > https://db.apache.org/torque/torque-3.3/releases/torque-3.3/generator/schema-reference.html -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-330) Postgresql fails for some prepared statement replacement types (short, double ...)
[ https://issues.apache.org/jira/browse/TORQUE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-330. --- Resolution: Fixed > Postgresql fails for some prepared statement replacement types (short, double > ...) > -- > > Key: TORQUE-330 > URL: https://issues.apache.org/jira/browse/TORQUE-330 > Project: Torque > Issue Type: Bug > Components: Runtime > Environment: postgresql >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > When executing a SQL statement with some prepared statement replacement types > (short, double ...) on the current trunk version, postgresql fails with an > error, e.g. ERROR: operator does not exist: smallint = character varying > This error is caught by the test > org.apache.torque.generated.peer.RetrieveByPkTest.testRetrieveByNonExistingPkMultiplePKs() > in the test project. > The reason is that in > org.apache.torque.util.BasePeerImpl.setPreparedStatementReplacements(PreparedStatement, > List, int) in the runtime, not all of these arguments are > considered, and for unknown arguments, > java.sql.PreparedStatement.setString(int, String) is used. > The setPreparedStatementReplacements method should be changed such that also > the specific setters for short, byte, float and double are used. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Updated] (TORQUE-330) Postgresql fails for some prepared statement replacement types (short, double ...)
[ https://issues.apache.org/jira/browse/TORQUE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox updated TORQUE-330: -- Description: When executing a SQL statement with some prepared statement replacement types (short, double ...) on the current trunk version, postgresql fails with an error, e.g. ERROR: operator does not exist: smallint = character varying This error is caught by the test org.apache.torque.generated.peer.RetrieveByPkTest.testRetrieveByNonExistingPkMultiplePKs() in the test project. The reason is that in org.apache.torque.util.BasePeerImpl.setPreparedStatementReplacements(PreparedStatement, List, int) in the runtime, not all of these arguments are considered, and for unknown arguments, java.sql.PreparedStatement.setString(int, String) is used. The setPreparedStatementReplacements method should be changed such that also the specific setters for short, byte, float and double are used. was: When executing a SQL statement with some prepared statement replacement types (short, double ...), postgresql fails with an error, e.g. ERROR: operator does not exist: smallint = character varying This error is caught by the test org.apache.torque.generated.peer.RetrieveByPkTest.testRetrieveByNonExistingPkMultiplePKs() in the test project. The reason is that in org.apache.torque.util.BasePeerImpl.setPreparedStatementReplacements(PreparedStatement, List, int) in the runtime, not all of these arguments are considered, and for unknown arguments, java.sql.PreparedStatement.setString(int, String) is used. The setPreparedStatementReplacements method should be changed such that also the specific setters for short, byte, float and double are used. Affects Version/s: (was: 4.0) > Postgresql fails for some prepared statement replacement types (short, double > ...) > -- > > Key: TORQUE-330 > URL: https://issues.apache.org/jira/browse/TORQUE-330 > Project: Torque > Issue Type: Bug > Components: Runtime > Environment: postgresql >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > When executing a SQL statement with some prepared statement replacement types > (short, double ...) on the current trunk version, postgresql fails with an > error, e.g. ERROR: operator does not exist: smallint = character varying > This error is caught by the test > org.apache.torque.generated.peer.RetrieveByPkTest.testRetrieveByNonExistingPkMultiplePKs() > in the test project. > The reason is that in > org.apache.torque.util.BasePeerImpl.setPreparedStatementReplacements(PreparedStatement, > List, int) in the runtime, not all of these arguments are > considered, and for unknown arguments, > java.sql.PreparedStatement.setString(int, String) is used. > The setPreparedStatementReplacements method should be changed such that also > the specific setters for short, byte, float and double are used. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-330) Postgresql fails for some prepared statement replacement types (short, double ...)
Thomas Fox created TORQUE-330: - Summary: Postgresql fails for some prepared statement replacement types (short, double ...) Key: TORQUE-330 URL: https://issues.apache.org/jira/browse/TORQUE-330 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 4.0 Environment: postgresql Reporter: Thomas Fox Assignee: Thomas Fox Fix For: 4.1 When executing a SQL statement with some prepared statement replacement types (short, double ...), postgresql fails with an error, e.g. ERROR: operator does not exist: smallint = character varying This error is caught by the test org.apache.torque.generated.peer.RetrieveByPkTest.testRetrieveByNonExistingPkMultiplePKs() in the test project. The reason is that in org.apache.torque.util.BasePeerImpl.setPreparedStatementReplacements(PreparedStatement, List, int) in the runtime, not all of these arguments are considered, and for unknown arguments, java.sql.PreparedStatement.setString(int, String) is used. The setPreparedStatementReplacements method should be changed such that also the specific setters for short, byte, float and double are used. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-320) GroupBy adds columns to the select clause
[ https://issues.apache.org/jira/browse/TORQUE-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-320. --- Resolution: Fixed Fix Version/s: 4.1 I have created a test case in the test project which checks a group by statement without adding the column to the select clause. The test case is green for all six supported databases. Thomas, please review the test cause and double-check that I have not missed anything. Feel free to re-open the issue if you feel that a test case is missing or something else is wrong. > GroupBy adds columns to the select clause > - > > Key: TORQUE-320 > URL: https://issues.apache.org/jira/browse/TORQUE-320 > Project: Torque > Issue Type: Bug > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > If I create a Criteria, define the select columns manually and then add > groupBy Columns, SqlBuilder adds the groupBy Columns to the select columns > One should be able to create GROUP BY Queries without adding the columns to > the select clause -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-329) Create better schema documentaion
Thomas Fox created TORQUE-329: - Summary: Create better schema documentaion Key: TORQUE-329 URL: https://issues.apache.org/jira/browse/TORQUE-329 Project: Torque Issue Type: Improvement Components: Documentation Affects Versions: 4.0 Reporter: Youngho Cho It would be great if a schema-reference document would exist like in torque-3.3 https://db.apache.org/torque/torque-3.3/releases/torque-3.3/generator/schema-reference.html -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-328) Use builder pattern throughout criteria
[ https://issues.apache.org/jira/browse/TORQUE-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-328. --- Resolution: Fixed > Use builder pattern throughout criteria > --- > > Key: TORQUE-328 > URL: https://issues.apache.org/jira/browse/TORQUE-328 > Project: Torque > Issue Type: Bug > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > Currently, most of Criteria's modifying methods return this as result and > thus Criteria can be used like a builder. > However, some public methods (setDistinct, setAll, setDbName, setFetchSize) > do not return anything. > These methods should return Criteria to allow easier usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-328) Use builder pattern throughout criteria
Thomas Fox created TORQUE-328: - Summary: Use builder pattern throughout criteria Key: TORQUE-328 URL: https://issues.apache.org/jira/browse/TORQUE-328 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 4.0 Reporter: Thomas Fox Assignee: Thomas Fox Fix For: 4.1 Currently, most of Criteria's modifying methods return this as result and thus Criteria can be used like a builder. However, some public methods (setDistinct, setAll, setDbName, setFetchSize) do not return anything. These methods should return Criteria to allow easier usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-320) GroupBy adds columns to the select clause
[ https://issues.apache.org/jira/browse/TORQUE-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox reassigned TORQUE-320: - Assignee: Thomas Fox > GroupBy adds columns to the select clause > - > > Key: TORQUE-320 > URL: https://issues.apache.org/jira/browse/TORQUE-320 > Project: Torque > Issue Type: Bug > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > > If I create a Criteria, define the select columns manually and then add > groupBy Columns, SqlBuilder adds the groupBy Columns to the select columns > One should be able to create GROUP BY Queries without adding the columns to > the select clause -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-323) Error in schema.xml for cascade="none" with postgresql
[ https://issues.apache.org/jira/browse/TORQUE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-323. --- Resolution: Cannot Reproduce Assignee: Thomas Fox I cannot reproduce the described behaviour. Please feel free to reopen the issue with an attached exmple schema and generation configuration with which the problem can be reproduced. > Error in schema.xml for cascade="none" with postgresql > -- > > Key: TORQUE-323 > URL: https://issues.apache.org/jira/browse/TORQUE-323 > Project: Torque > Issue Type: Bug >Affects Versions: 4.0 > Environment: Postgresql 9.3.4 Java 8, on 64bit x86 Fedora. >Reporter: Martin Tilsted >Assignee: Thomas Fox > > If you in your schema.xml have a > > Then torque will generate the following in schema.sql: > ALTER TABLE book > ADD CONSTRAINT book_FK_1 > FOREIGN KEY (keyref) > REFERENCES keyreftable (id) > ON UPDATE NONE > ON DELETE NONE; > But postgresql don't accept the syntax "On update none" and "on delete none" > It should be "on update no action" and "on delete no action" instead. > Since onUpdate="none" is the default if no onUpdate value have been set in > schema.xml, this make it imposible to generate the database from the sql, > unless onUpdate and onDelete explicit have been specified to something other > then none on all foreign keys. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-323) Error in schema.xml for cascade="none" with postgresql
[ https://issues.apache.org/jira/browse/TORQUE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14145667#comment-14145667 ] Thomas Fox commented on TORQUE-323: --- Note: in current trunk the schema locateion has changed: xsi:schemaLocation="http://db.apache.org/torque/4.0/templates/database http://db.apache.org/torque/torque-4.0/documentation/orm-reference/database-4-0.xsd"; > Error in schema.xml for cascade="none" with postgresql > -- > > Key: TORQUE-323 > URL: https://issues.apache.org/jira/browse/TORQUE-323 > Project: Torque > Issue Type: Bug >Affects Versions: 4.0 > Environment: Postgresql 9.3.4 Java 8, on 64bit x86 Fedora. >Reporter: Martin Tilsted > > If you in your schema.xml have a > > Then torque will generate the following in schema.sql: > ALTER TABLE book > ADD CONSTRAINT book_FK_1 > FOREIGN KEY (keyref) > REFERENCES keyreftable (id) > ON UPDATE NONE > ON DELETE NONE; > But postgresql don't accept the syntax "On update none" and "on delete none" > It should be "on update no action" and "on delete no action" instead. > Since onUpdate="none" is the default if no onUpdate value have been set in > schema.xml, this make it imposible to generate the database from the sql, > unless onUpdate and onDelete explicit have been specified to something other > then none on all foreign keys. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-278) There should not be a create table command in the generated sql for tables from a external schema
[ https://issues.apache.org/jira/browse/TORQUE-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-278. --- Resolution: Fixed Fix Version/s: 4.1 > There should not be a create table command in the generated sql for tables > from a external schema > - > > Key: TORQUE-278 > URL: https://issues.apache.org/jira/browse/TORQUE-278 > Project: Torque > Issue Type: Bug > Components: Templates >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > Currently, the tables from external schemata are dropped and created in the > created sql. > This should not be the case, tables from external-schem should not appear in > the schema sql -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-322) Support for SQL Set Operations (UNION, INTERSECT, ...)
[
https://issues.apache.org/jira/browse/TORQUE-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox resolved TORQUE-322.
---
Resolution: Fixed
Fix Version/s: 4.1
> Support for SQL Set Operations (UNION, INTERSECT, ...)
> --
>
> Key: TORQUE-322
> URL: https://issues.apache.org/jira/browse/TORQUE-322
> Project: Torque
> Issue Type: New Feature
>Affects Versions: 4.0
>Reporter: Michael Wa
>Assignee: Thomas Fox
> Fix For: 4.1
>
>
> * It would be nice to support sql constructs like:
> SELECT * FROM sales2005 UNION SELECT * FROM sales2006;
> * If you want to realize the UNION operator you have to do something like
> that:
> [...]
> Criteria criteriaA = new Criteria();
> criteriaA.where( ... );
> criteriaA.addSelectColumn(COLUMNX);
> Query queryA = SqlBuilder.buildQuery(criteriaA);
> String sqlA = queryA.toString();
> List replacementsA = queryA.getPreparedStatementReplacements();
> Criteria criteriaB = new Criteria();
> criteriaB.where( ... );
> criteriaB.addSelectColumn(...);
> Query queryB = SqlBuilder.buildQuery(criteriaB);
> String sqlB = queryB.toString();
> List replacementsB = queryB.getPreparedStatementReplacements();
> List replacements = Lists.newArrayList();
> replacements.addAll(replacementsA);
> replacements.addAll(replacementsB);
> String sql = COLUMNX + " IN (" + sqlA + " UNION " + sqlB + ")";
> mainCriteria.whereVerbatimSql(sql, replacements.toArray());
> [...]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-322) Support for SQL Set Operations (UNION, INTERSECT, ...)
[
https://issues.apache.org/jira/browse/TORQUE-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126268#comment-14126268
]
Thomas Fox commented on TORQUE-322:
---
According to http://en.wikipedia.org/wiki/Set_operations_%28SQL%29, there are
three SET operations, namely UNION, INTERSECT and EXCEPT .Each operation can be
suffixed by ALL (do not remove duplicate rows) or DISTINCT (do remove duplicate
rows). The standard behavior is DISTINCT.
Support from the supported databases for the set operators:
Oracle: According to
http://docs.oracle.com/cd/B19306_01/server.102/b14200/queries004.htm, Oracle
supports UNION [ALL], INTERSECT and MINUS, where it seems from the description
that MINUS is functionally equivalent to EXCEPT.
Mysql: According to http://dev.mysql.com/doc/refman/5.7/en/union.html, MySQL
supports UNION and UNION ALL. I did not find any support for INTERSECT and
EXCEPT.
Postgresql: According to
http://www.postgresql.org/docs/7.4/static/sql-select.html, all set operations
are supported by Postgresql.
Derby: According to
https://db.apache.org/derby/docs/10.7/ref/rrefsqlj21571.html, all set
operations are supported by Derby.
Hsqldb: According to http://www.hsqldb.org/doc/guide/ch09.html, hsqldb supports
UNION, UNION ALL, MINUS, EXCEPT and INTERSECT.
Mssql: According to http://msdn.microsoft.com/de-de/library/ms188055.aspx,
Mssql supports UNION [ALL], EXCEPT and INTERSECT.
Execution order is also different for databases. E.g. Oracle 10g evaluates all
operations from left to right, while in postgresql, the intersect command has
higher precedence.
Conclusion: all six combinations (three operators and the ALL variant) should
be supported. It need not be tracked which operation is supported by which
database (this would make the adapter class very fat); however it should be
tracked in the tests. It needs to be tracked in the adapter whether MINUS must
be used instead of EXCEPT (true for oracle, false for others). There should be
some means to control parenthesis (a UNION (b INTERSECT C) vs (a UNION b)
INTERSECT c.
> Support for SQL Set Operations (UNION, INTERSECT, ...)
> --
>
> Key: TORQUE-322
> URL: https://issues.apache.org/jira/browse/TORQUE-322
> Project: Torque
> Issue Type: New Feature
>Affects Versions: 4.0
>Reporter: Michael Wa
>Assignee: Thomas Fox
>
> * It would be nice to support sql constructs like:
> SELECT * FROM sales2005 UNION SELECT * FROM sales2006;
> * If you want to realize the UNION operator you have to do something like
> that:
> [...]
> Criteria criteriaA = new Criteria();
> criteriaA.where( ... );
> criteriaA.addSelectColumn(COLUMNX);
> Query queryA = SqlBuilder.buildQuery(criteriaA);
> String sqlA = queryA.toString();
> List replacementsA = queryA.getPreparedStatementReplacements();
> Criteria criteriaB = new Criteria();
> criteriaB.where( ... );
> criteriaB.addSelectColumn(...);
> Query queryB = SqlBuilder.buildQuery(criteriaB);
> String sqlB = queryB.toString();
> List replacementsB = queryB.getPreparedStatementReplacements();
> List replacements = Lists.newArrayList();
> replacements.addAll(replacementsA);
> replacements.addAll(replacementsB);
> String sql = COLUMNX + " IN (" + sqlA + " UNION " + sqlB + ")";
> mainCriteria.whereVerbatimSql(sql, replacements.toArray());
> [...]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-322) Support for SQL Set Operations (UNION, INTERSECT, ...)
[
https://issues.apache.org/jira/browse/TORQUE-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox reassigned TORQUE-322:
-
Assignee: Thomas Fox
> Support for SQL Set Operations (UNION, INTERSECT, ...)
> --
>
> Key: TORQUE-322
> URL: https://issues.apache.org/jira/browse/TORQUE-322
> Project: Torque
> Issue Type: New Feature
>Affects Versions: 4.0
>Reporter: Michael Wa
>Assignee: Thomas Fox
>
> * It would be nice to support sql constructs like:
> SELECT * FROM sales2005 UNION SELECT * FROM sales2006;
> * If you want to realize the UNION operator you have to do something like
> that:
> [...]
> Criteria criteriaA = new Criteria();
> criteriaA.where( ... );
> criteriaA.addSelectColumn(COLUMNX);
> Query queryA = SqlBuilder.buildQuery(criteriaA);
> String sqlA = queryA.toString();
> List replacementsA = queryA.getPreparedStatementReplacements();
> Criteria criteriaB = new Criteria();
> criteriaB.where( ... );
> criteriaB.addSelectColumn(...);
> Query queryB = SqlBuilder.buildQuery(criteriaB);
> String sqlB = queryB.toString();
> List replacementsB = queryB.getPreparedStatementReplacements();
> List replacements = Lists.newArrayList();
> replacements.addAll(replacementsA);
> replacements.addAll(replacementsB);
> String sql = COLUMNX + " IN (" + sqlA + " UNION " + sqlB + ")";
> mainCriteria.whereVerbatimSql(sql, replacements.toArray());
> [...]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-326) Setters in Criterion can be used for composite Criterion
[ https://issues.apache.org/jira/browse/TORQUE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-326. --- Resolution: Fixed > Setters in Criterion can be used for composite Criterion > > > Key: TORQUE-326 > URL: https://issues.apache.org/jira/browse/TORQUE-326 > Project: Torque > Issue Type: Bug > Components: Runtime >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox >Priority: Minor > Fix For: 4.1 > > > Currently, the public setters Citeria.setLValue(), Citeria.setRValue() and > Criteria.setIgnoreCase() can be used for composite Criterions. > These values are ignored for composite Criterions. > Therefore, it should not be possible to call these setters for composite > Criterions. > Instead, a IllegalStateException should be thrown whenenever these setters > are called on a composite Criterion -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-326) Setters in Criterion can be used for composite Criterion
Thomas Fox created TORQUE-326: - Summary: Setters in Criterion can be used for composite Criterion Key: TORQUE-326 URL: https://issues.apache.org/jira/browse/TORQUE-326 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 4.0 Reporter: Thomas Fox Assignee: Thomas Fox Priority: Minor Fix For: 4.1 Currently, the public setters Citeria.setLValue(), Citeria.setRValue() and Criteria.setIgnoreCase() can be used for composite Criterions. These values are ignored for composite Criterions. Therefore, it should not be possible to call these setters for composite Criterions. Instead, a IllegalStateException should be thrown whenenever these setters are called on a composite Criterion -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-315) setAndSave does not work if the cached collection from the object is passed in
[ https://issues.apache.org/jira/browse/TORQUE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-315. --- Resolution: Fixed Assignee: Thomas Fox > setAndSave does not work if the cached collection from the object is passed in > -- > > Key: TORQUE-315 > URL: https://issues.apache.org/jira/browse/TORQUE-315 > Project: Torque > Issue Type: Bug > Components: Templates >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > example > AuthorPeer.setAndSaveBooks(author, author.getBooks()) > clears the cached list -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-313) setAndSave does not work with new objects
[ https://issues.apache.org/jira/browse/TORQUE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-313. --- Resolution: Fixed This was probably resoved by fixing TORQUE-291 or TORQUE-315. There are several test cases in org.apache.torque.generated.peer.SetAndSaveTest in the test project which are checking that new objects are treated correctly. > setAndSave does not work with new objects > - > > Key: TORQUE-313 > URL: https://issues.apache.org/jira/browse/TORQUE-313 > Project: Torque > Issue Type: Bug >Affects Versions: 4.1 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > New objects are ignored in the passed collection. They should also be saved. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-308) wrong schema location for XSDs
[ https://issues.apache.org/jira/browse/TORQUE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-308. --- Resolution: Fixed Fix Version/s: 4.1 Assignee: Thomas Fox > wrong schema location for XSDs > -- > > Key: TORQUE-308 > URL: https://issues.apache.org/jira/browse/TORQUE-308 > Project: Torque > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > The schema location in the current 4.0 xsds is wrong. > It should be > http://db.apache.org/torque/torque-4.0/documentation/orm-reference/database-4-0-strict.xsd -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-281) Only issue SQL update with columns whose value is changed in dbObject, since it was loaded from db
[ https://issues.apache.org/jira/browse/TORQUE-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox reassigned TORQUE-281: - Assignee: (was: Thomas Fox) > Only issue SQL update with columns whose value is changed in dbObject, since > it was loaded from db > -- > > Key: TORQUE-281 > URL: https://issues.apache.org/jira/browse/TORQUE-281 > Project: Torque > Issue Type: Improvement >Reporter: rajguru > > This means dbObject needs to have a way to see oldValue and newValue. If so > also provide some hooks in the code before update/after update/before > insert/after insert/before delete and after delete, so one can plugin an > auditing code to log the oldValue to newValue change -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-317) BaseBean does generate fields for referencing objects
[
https://issues.apache.org/jira/browse/TORQUE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14124586#comment-14124586
]
Thomas Fox commented on TORQUE-317:
---
The same for useManagers, this switch is also needed per table in the tests
> BaseBean does generate fields for referencing objects
> -
>
> Key: TORQUE-317
> URL: https://issues.apache.org/jira/browse/TORQUE-317
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
> Environment: Centos 6.4, Java 8
>Reporter: Rob Decker
>Assignee: Thomas Fox
>Priority: Critical
> Fix For: 4.1
>
>
> In the baseBean.vm template the field definitions for referenced objects
> mergepoints are present but the generated beans do not contain the fields.
> The methods do properly reference the fields but the code does not compile
> because the field declarations are missing.
> ## field definitions for referenced objects
> #if ($torqueGen.booleanOption("torque.om.complexObjectModel"))
> $torqueGen.mergepoint("fieldDefinitionsReferencedObjects")
> ##
> ## field definitions for referencing objects
> $torqueGen.mergepoint("fieldDefinitionsReferencingObjects")
> #end
> I am not familiar enough with templates to figure why it isn't working.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-317) BaseBean does generate fields for referencing objects
[
https://issues.apache.org/jira/browse/TORQUE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox resolved TORQUE-317.
---
Resolution: Fixed
Fix Version/s: 4.1
> BaseBean does generate fields for referencing objects
> -
>
> Key: TORQUE-317
> URL: https://issues.apache.org/jira/browse/TORQUE-317
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
> Environment: Centos 6.4, Java 8
>Reporter: Rob Decker
>Assignee: Thomas Fox
>Priority: Critical
> Fix For: 4.1
>
>
> In the baseBean.vm template the field definitions for referenced objects
> mergepoints are present but the generated beans do not contain the fields.
> The methods do properly reference the fields but the code does not compile
> because the field declarations are missing.
> ## field definitions for referenced objects
> #if ($torqueGen.booleanOption("torque.om.complexObjectModel"))
> $torqueGen.mergepoint("fieldDefinitionsReferencedObjects")
> ##
> ## field definitions for referencing objects
> $torqueGen.mergepoint("fieldDefinitionsReferencingObjects")
> #end
> I am not familiar enough with templates to figure why it isn't working.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-317) BaseBean does generate fields for referencing objects
[
https://issues.apache.org/jira/browse/TORQUE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121963#comment-14121963
]
Thomas Fox commented on TORQUE-317:
---
The only drawback is that the option is then not overrideable per table. So not
to destroy current tests, saveMethodsInDbObjects is tesded against "true" and
not as booleanOption
> BaseBean does generate fields for referencing objects
> -
>
> Key: TORQUE-317
> URL: https://issues.apache.org/jira/browse/TORQUE-317
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
> Environment: Centos 6.4, Java 8
>Reporter: Rob Decker
>Assignee: Thomas Fox
>Priority: Critical
>
> In the baseBean.vm template the field definitions for referenced objects
> mergepoints are present but the generated beans do not contain the fields.
> The methods do properly reference the fields but the code does not compile
> because the field declarations are missing.
> ## field definitions for referenced objects
> #if ($torqueGen.booleanOption("torque.om.complexObjectModel"))
> $torqueGen.mergepoint("fieldDefinitionsReferencedObjects")
> ##
> ## field definitions for referencing objects
> $torqueGen.mergepoint("fieldDefinitionsReferencingObjects")
> #end
> I am not familiar enough with templates to figure why it isn't working.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-317) BaseBean does generate fields for referencing objects
[
https://issues.apache.org/jira/browse/TORQUE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121890#comment-14121890
]
Thomas Fox commented on TORQUE-317:
---
It would be good if torque would ignore trailing spaces in boolean options.
So the idea is to fix torqueGen.booleanOption() such that it ignores trailing
spaces, and replace the checks =="true" by torqueGen.booleanOption()
> BaseBean does generate fields for referencing objects
> -
>
> Key: TORQUE-317
> URL: https://issues.apache.org/jira/browse/TORQUE-317
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
> Environment: Centos 6.4, Java 8
>Reporter: Rob Decker
>Assignee: Thomas Fox
>Priority: Critical
>
> In the baseBean.vm template the field definitions for referenced objects
> mergepoints are present but the generated beans do not contain the fields.
> The methods do properly reference the fields but the code does not compile
> because the field declarations are missing.
> ## field definitions for referenced objects
> #if ($torqueGen.booleanOption("torque.om.complexObjectModel"))
> $torqueGen.mergepoint("fieldDefinitionsReferencedObjects")
> ##
> ## field definitions for referencing objects
> $torqueGen.mergepoint("fieldDefinitionsReferencingObjects")
> #end
> I am not familiar enough with templates to figure why it isn't working.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-310) add simple way to remove unused imports
[ https://issues.apache.org/jira/browse/TORQUE-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-310. --- Resolution: Fixed > add simple way to remove unused imports > --- > > Key: TORQUE-310 > URL: https://issues.apache.org/jira/browse/TORQUE-310 > Project: Torque > Issue Type: Improvement > Components: Generator, Templates >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > One could check for lines starting with "import" and then check whether these > imported Strings occur at another place in the file. If not, it should be > safe to remove the import line. > This does not work in all situations, e.g. if the Class name occurs in a > commoent but nowhere else (then the import is not removed though it should > be), but should be good enough for 99% of cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-309) Add interface to generated peer classes
[ https://issues.apache.org/jira/browse/TORQUE-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-309. --- Resolution: Fixed Assignee: Thomas Fox Thanks for the patch, it was applied with some small changes. > Add interface to generated peer classes > --- > > Key: TORQUE-309 > URL: https://issues.apache.org/jira/browse/TORQUE-309 > Project: Torque > Issue Type: Improvement > Components: Templates >Affects Versions: 4.0 > Environment: tested on windows >Reporter: Georg Kallidis >Assignee: Thomas Fox >Priority: Minor > Fix For: 4.1 > > Attachments: torque-templates-peerInterface.patch > > > PeerImp classes should also be able to have generated interface analog the > existing interface attribute, cft. > http://db.apache.org/torque/torque-4.0/documentation/orm-reference/database-4-0.xsd. > This could be done quite the same way, just using peerInterface instead of > interface. A patch is provided in attachement (tested win7, java 1.7_51). > This would solve https://issues.apache.org/jira/browse/TRB-92. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-321) Wrong optimization of iLike without wildcards
[
https://issues.apache.org/jira/browse/TORQUE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox resolved TORQUE-321.
---
Resolution: Fixed
Fix Version/s: 4.1
> Wrong optimization of iLike without wildcards
> --
>
> Key: TORQUE-321
> URL: https://issues.apache.org/jira/browse/TORQUE-321
> Project: Torque
> Issue Type: Bug
> Components: Runtime
>Affects Versions: 4.0
> Environment: Using java 8 and Postgresql 9.3.4.
>Reporter: Martin Tilsted
>Assignee: Thomas Fox
> Fix For: 4.1
>
>
> Torque transform a criteria with SqlEnum.ILIKE to a simple compare using(=)
> if the string it searches for don't contain any wildcards.
> But this optimization is not valid, because ILIKE also does a case
> insensitive compare. This bug causes ILIKE to behave like LIKE when not using
> any wildcards.
> Example code:
> Criteria c=new Criteria();
> c.and(VoucherinstancePeer.CODE,"myCode",SqlEnum.ILIKE);
> log.debug("Got criteria=" + c);
> c=new Criteria();
> c.and(VoucherinstancePeer.CODE,"myCode%",SqlEnum.ILIKE);
> log.debug("Got criteria=" + c);
> Gives this output:
> DEBUG - Got criteria=Criteria: Current Query SQL (may not be complete or
> applicable): SELECT FROM voucherInstance WHERE voucherInstance.code=?
> Replacements: [myCode]
> DEBUG - Got criteria=Criteria: Current Query SQL (may not be complete or
> applicable): SELECT FROM voucherInstance WHERE voucherInstance.code ILIKE ?
> Replacements: [myCode%]
> where the invalid transformation can be seen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-312) NPE in generation process
[ https://issues.apache.org/jira/browse/TORQUE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-312. --- Resolution: Fixed > NPE in generation process > - > > Key: TORQUE-312 > URL: https://issues.apache.org/jira/browse/TORQUE-312 > Project: Torque > Issue Type: Bug > Components: Generator, Templates >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > In a generation process, the following NPE appeared. Supposed reason is that > a foreign key does not have a corresponding local column > java.lang.NullPointerException > at > org.apache.torque.generator.source.SourceElement$ChildList.add(SourceElement.java:691) > at > org.apache.torque.generator.source.SourceElement$ChildList.add(SourceElement.java:642) > at java.util.AbstractList.add(AbstractList.java:108) > at > org.apache.torque.templates.transformer.om.OMForeignKeyTransformer.createLocalElementForReference(OMForeignKeyTransformer.java:776) > at > org.apache.torque.templates.transformer.om.OMForeignKeyTransformer.transform(OMForeignKeyTransformer.java:91) > at > org.apache.torque.templates.transformer.om.OMTransformer.transform(OMTransformer.java:168) > at > org.apache.torque.generator.control.Controller.transformSource(Controller.java:547) > at > org.apache.torque.generator.control.Controller.processSourceInOutput(Controller.java:260) > at > org.apache.torque.generator.control.Controller.processOutput(Controller.java:228) > at > org.apache.torque.generator.control.Controller.processGenerationUnit(Controller.java:181) > at > org.apache.torque.generator.control.Controller.run(Controller.java:111) > at > org.apache.torque.generator.maven.TorqueGeneratorMojo.execute(TorqueGeneratorMojo.java:678) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-312) NPE in generation process
[ https://issues.apache.org/jira/browse/TORQUE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14120322#comment-14120322 ] Thomas Fox commented on TORQUE-312: --- The supposed reason has been confirmed. > NPE in generation process > - > > Key: TORQUE-312 > URL: https://issues.apache.org/jira/browse/TORQUE-312 > Project: Torque > Issue Type: Bug > Components: Generator, Templates >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > In a generation process, the following NPE appeared. Supposed reason is that > a foreign key does not have a corresponding local column > java.lang.NullPointerException > at > org.apache.torque.generator.source.SourceElement$ChildList.add(SourceElement.java:691) > at > org.apache.torque.generator.source.SourceElement$ChildList.add(SourceElement.java:642) > at java.util.AbstractList.add(AbstractList.java:108) > at > org.apache.torque.templates.transformer.om.OMForeignKeyTransformer.createLocalElementForReference(OMForeignKeyTransformer.java:776) > at > org.apache.torque.templates.transformer.om.OMForeignKeyTransformer.transform(OMForeignKeyTransformer.java:91) > at > org.apache.torque.templates.transformer.om.OMTransformer.transform(OMTransformer.java:168) > at > org.apache.torque.generator.control.Controller.transformSource(Controller.java:547) > at > org.apache.torque.generator.control.Controller.processSourceInOutput(Controller.java:260) > at > org.apache.torque.generator.control.Controller.processOutput(Controller.java:228) > at > org.apache.torque.generator.control.Controller.processGenerationUnit(Controller.java:181) > at > org.apache.torque.generator.control.Controller.run(Controller.java:111) > at > org.apache.torque.generator.maven.TorqueGeneratorMojo.execute(TorqueGeneratorMojo.java:678) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-325) Oracle sql files contain additional empty lines before ON DELETE token
[ https://issues.apache.org/jira/browse/TORQUE-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-325. --- Resolution: Fixed Assignee: Thomas Fox > Oracle sql files contain additional empty lines before ON DELETE token > -- > > Key: TORQUE-325 > URL: https://issues.apache.org/jira/browse/TORQUE-325 > Project: Torque > Issue Type: Improvement > Components: Templates >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox >Priority: Minor > Fix For: 4.1 > > > These empty lines can cause some oracle sql processing tools to choke, so > they should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-325) Oracle sql files contain additional empty lines before ON DELETE token
Thomas Fox created TORQUE-325: - Summary: Oracle sql files contain additional empty lines before ON DELETE token Key: TORQUE-325 URL: https://issues.apache.org/jira/browse/TORQUE-325 Project: Torque Issue Type: Improvement Components: Templates Affects Versions: 4.0 Reporter: Thomas Fox Priority: Minor Fix For: 4.1 These empty lines can cause some oracle sql processing tools to choke, so they should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-318) retrieveByPK throws TorqueException instead of NoRowsException when it can't find a primary key.
[
https://issues.apache.org/jira/browse/TORQUE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox resolved TORQUE-318.
---
Resolution: Fixed
Fix Version/s: 4.1
> retrieveByPK throws TorqueException instead of NoRowsException when it can't
> find a primary key.
>
>
> Key: TORQUE-318
> URL: https://issues.apache.org/jira/browse/TORQUE-318
> Project: Torque
> Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Martin Tilsted
>Assignee: Thomas Fox
> Fix For: 4.1
>
>
> I have the following in my schema.xml:
>
>
>
>
>
>
> Which then generate the following code in my Peer class.
> /**
> * retrieve object using using pk values.
> *
> * @param juusuuserref int
> * @param entryid int
> * @param entrytype int
> * @param con Connection
> */
> public static Juusuread retrieveByPK(
> int juusuuserref,
> int entryid,
> int entrytype,
> Connection con) throws TorqueException
> {
>
> }
> But this retrieveByPK will throw a
> TorqueException("Failed to select one and only one row.")
> instead of a NoRowsException as expected if it can't find a entry in the
> database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-316) saveMethods.vm has toSave.setNew instead of a using toSaveVariableWithDot
[
https://issues.apache.org/jira/browse/TORQUE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox resolved TORQUE-316.
---
Resolution: Fixed
Fix Version/s: 4.1
> saveMethods.vm has toSave.setNew instead of a using toSaveVariableWithDot
> -
>
> Key: TORQUE-316
> URL: https://issues.apache.org/jira/browse/TORQUE-316
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
>Reporter: Rob Decker
>Assignee: Thomas Fox
>Priority: Critical
> Fix For: 4.1
>
>
> When I generate classes with
> torque.om.addSaveMethods=true
> torque.om.saveMethodsInDbObjects=true
> The dbobjects won't compile because the line toSave.setNew(false) is not a
> variable. I updated the saveMethods.vm template to fix the issue with this:
> diff
> torque-templates-4.0-new/org/apache/torque/templates/om/templates/general/saveMethods.vm
>
> torque-templates-4.0-orig/org/apache/torque/templates/om/templates/general/saveMethods.vm
> 65c65
> < ${toSaveVariableWithDot}setNew(false);
> ---
> > toSave.setNew(false);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-324) In the generator, the parent node should be referenceable with ..
[ https://issues.apache.org/jira/browse/TORQUE-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-324. --- Resolution: Fixed > In the generator, the parent node should be referenceable with .. > - > > Key: TORQUE-324 > URL: https://issues.apache.org/jira/browse/TORQUE-324 > Project: Torque > Issue Type: Improvement > Components: Generator >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > Currently, it is not possible to use .. (access the parent element) in the > xpath in the generator to get the parent of the currently processed source > element. This should be possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Created] (TORQUE-324) In the generator, the parent node should be referenceable with ..
Thomas Fox created TORQUE-324: - Summary: In the generator, the parent node should be referenceable with .. Key: TORQUE-324 URL: https://issues.apache.org/jira/browse/TORQUE-324 Project: Torque Issue Type: Improvement Components: Generator Affects Versions: 4.0 Reporter: Thomas Fox Assignee: Thomas Fox Fix For: 4.1 Currently, it is not possible to use .. (access the parent element) in the xpath in the generator to get the parent of the currently processed source element. This should be possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-319) No KEYS file; download page link is broken
[ https://issues.apache.org/jira/browse/TORQUE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox reassigned TORQUE-319: - Assignee: Thomas Fox > No KEYS file; download page link is broken > -- > > Key: TORQUE-319 > URL: https://issues.apache.org/jira/browse/TORQUE-319 > Project: Torque > Issue Type: Bug >Reporter: Sebb >Assignee: Thomas Fox >Priority: Blocker > > There is no KEYS file on the ASF mirror. > The link to the KEYS on the download page is broken. > Please ensure that the KEYS file is added to > http://www.apache.org/dist/db/torque/ > Note: since this will be saved to the archive server, please ensure that keys > are never removed from the file, otherwise it won't be possible to check sigs > for older releases. > There is already a file at > http://archive.apache.org/dist/db/torque/ > which can be used as a basis for the new one. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-319) No KEYS file; download page link is broken
[ https://issues.apache.org/jira/browse/TORQUE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-319. --- Resolution: Fixed > No KEYS file; download page link is broken > -- > > Key: TORQUE-319 > URL: https://issues.apache.org/jira/browse/TORQUE-319 > Project: Torque > Issue Type: Bug >Reporter: Sebb >Priority: Blocker > > There is no KEYS file on the ASF mirror. > The link to the KEYS on the download page is broken. > Please ensure that the KEYS file is added to > http://www.apache.org/dist/db/torque/ > Note: since this will be saved to the archive server, please ensure that keys > are never removed from the file, otherwise it won't be possible to check sigs > for older releases. > There is already a file at > http://archive.apache.org/dist/db/torque/ > which can be used as a basis for the new one. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Resolved] (TORQUE-311) wrong example configuration in docs
[ https://issues.apache.org/jira/browse/TORQUE-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox resolved TORQUE-311. --- Resolution: Fixed Assignee: Thomas Fox > wrong example configuration in docs > --- > > Key: TORQUE-311 > URL: https://issues.apache.org/jira/browse/TORQUE-311 > Project: Torque > Issue Type: Bug > Components: Documentation >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox >Priority: Minor > Fix For: 4.1 > > > In the docs > http://db.apache.org/torque/torque-4.0/documentation/orm-reference/running-the-generator.html > the configuration parameters > compileNewFileTargetDir and compileModifiedFileTargetDir are mentioned. These > do not exist. Instead, defaultOutputDirUsage and outputDirUsageMap should be > used -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-317) BaseBean does generate fields for referencing objects
[
https://issues.apache.org/jira/browse/TORQUE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14107483#comment-14107483
]
Thomas Fox commented on TORQUE-317:
---
It could be that you have a trailing spaces problem.
>From your debug output there is a trailing space after "true" (shown below by
>surrounding the string with "" ):
Setting project property: torque.om.complexObjectModel -> "true "
Can you please check this ?
> BaseBean does generate fields for referencing objects
> -
>
> Key: TORQUE-317
> URL: https://issues.apache.org/jira/browse/TORQUE-317
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
> Environment: Centos 6.4, Java 8
>Reporter: Rob Decker
>Assignee: Thomas Fox
>Priority: Critical
>
> In the baseBean.vm template the field definitions for referenced objects
> mergepoints are present but the generated beans do not contain the fields.
> The methods do properly reference the fields but the code does not compile
> because the field declarations are missing.
> ## field definitions for referenced objects
> #if ($torqueGen.booleanOption("torque.om.complexObjectModel"))
> $torqueGen.mergepoint("fieldDefinitionsReferencedObjects")
> ##
> ## field definitions for referencing objects
> $torqueGen.mergepoint("fieldDefinitionsReferencingObjects")
> #end
> I am not familiar enough with templates to figure why it isn't working.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-312) NPE in generation process
[ https://issues.apache.org/jira/browse/TORQUE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Fox reassigned TORQUE-312: - Assignee: Thomas Fox > NPE in generation process > - > > Key: TORQUE-312 > URL: https://issues.apache.org/jira/browse/TORQUE-312 > Project: Torque > Issue Type: Bug > Components: Generator, Templates >Affects Versions: 4.0 >Reporter: Thomas Fox >Assignee: Thomas Fox > Fix For: 4.1 > > > In a generation process, the following NPE appeared. Supposed reason is that > a foreign key does not have a corresponding local column > java.lang.NullPointerException > at > org.apache.torque.generator.source.SourceElement$ChildList.add(SourceElement.java:691) > at > org.apache.torque.generator.source.SourceElement$ChildList.add(SourceElement.java:642) > at java.util.AbstractList.add(AbstractList.java:108) > at > org.apache.torque.templates.transformer.om.OMForeignKeyTransformer.createLocalElementForReference(OMForeignKeyTransformer.java:776) > at > org.apache.torque.templates.transformer.om.OMForeignKeyTransformer.transform(OMForeignKeyTransformer.java:91) > at > org.apache.torque.templates.transformer.om.OMTransformer.transform(OMTransformer.java:168) > at > org.apache.torque.generator.control.Controller.transformSource(Controller.java:547) > at > org.apache.torque.generator.control.Controller.processSourceInOutput(Controller.java:260) > at > org.apache.torque.generator.control.Controller.processOutput(Controller.java:228) > at > org.apache.torque.generator.control.Controller.processGenerationUnit(Controller.java:181) > at > org.apache.torque.generator.control.Controller.run(Controller.java:111) > at > org.apache.torque.generator.maven.TorqueGeneratorMojo.execute(TorqueGeneratorMojo.java:678) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-317) BaseBean does generate fields for referencing objects
[
https://issues.apache.org/jira/browse/TORQUE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14099778#comment-14099778
]
Thomas Fox commented on TORQUE-317:
---
There are wrong checks for the torque.om.complexObjectModel option in the
templates (velocity's #if checks if the string is set not if it i set to "true"
or "false")
In
/torque-templates/src/main/resources/org/apache/torque/templates/om/templates/bean/base/baseBean.vm
and in
/torque-templates/src/main/resources/org/apache/torque/templates/om/templates/bean/base/setterMethodEnd.vm,
the line
#if ($torqueGen.option("torque.om.complexObjectModel"))
must be replaced by
#if ($complexObjectModel == "true")
> BaseBean does generate fields for referencing objects
> -
>
> Key: TORQUE-317
> URL: https://issues.apache.org/jira/browse/TORQUE-317
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
> Environment: Centos 6.4, Java 8
>Reporter: Rob Decker
>Assignee: Thomas Fox
>Priority: Critical
>
> In the baseBean.vm template the field definitions for referenced objects
> mergepoints are present but the generated beans do not contain the fields.
> The methods do properly reference the fields but the code does not compile
> because the field declarations are missing.
> ## field definitions for referenced objects
> #if ($torqueGen.booleanOption("torque.om.complexObjectModel"))
> $torqueGen.mergepoint("fieldDefinitionsReferencedObjects")
> ##
> ## field definitions for referencing objects
> $torqueGen.mergepoint("fieldDefinitionsReferencingObjects")
> #end
> I am not familiar enough with templates to figure why it isn't working.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-317) BaseBean does generate fields for referencing objects
[
https://issues.apache.org/jira/browse/TORQUE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox reassigned TORQUE-317:
-
Assignee: Thomas Fox
> BaseBean does generate fields for referencing objects
> -
>
> Key: TORQUE-317
> URL: https://issues.apache.org/jira/browse/TORQUE-317
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
> Environment: Centos 6.4, Java 8
>Reporter: Rob Decker
>Assignee: Thomas Fox
>Priority: Critical
>
> In the baseBean.vm template the field definitions for referenced objects
> mergepoints are present but the generated beans do not contain the fields.
> The methods do properly reference the fields but the code does not compile
> because the field declarations are missing.
> ## field definitions for referenced objects
> #if ($torqueGen.booleanOption("torque.om.complexObjectModel"))
> $torqueGen.mergepoint("fieldDefinitionsReferencedObjects")
> ##
> ## field definitions for referencing objects
> $torqueGen.mergepoint("fieldDefinitionsReferencingObjects")
> #end
> I am not familiar enough with templates to figure why it isn't working.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Assigned] (TORQUE-316) saveMethods.vm has toSave.setNew instead of a using toSaveVariableWithDot
[
https://issues.apache.org/jira/browse/TORQUE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Fox reassigned TORQUE-316:
-
Assignee: Thomas Fox
> saveMethods.vm has toSave.setNew instead of a using toSaveVariableWithDot
> -
>
> Key: TORQUE-316
> URL: https://issues.apache.org/jira/browse/TORQUE-316
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
>Reporter: Rob Decker
>Assignee: Thomas Fox
>Priority: Critical
>
> When I generate classes with
> torque.om.addSaveMethods=true
> torque.om.saveMethodsInDbObjects=true
> The dbobjects won't compile because the line toSave.setNew(false) is not a
> variable. I updated the saveMethods.vm template to fix the issue with this:
> diff
> torque-templates-4.0-new/org/apache/torque/templates/om/templates/general/saveMethods.vm
>
> torque-templates-4.0-orig/org/apache/torque/templates/om/templates/general/saveMethods.vm
> 65c65
> < ${toSaveVariableWithDot}setNew(false);
> ---
> > toSave.setNew(false);
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-316) saveMethods.vm has toSave.setNew instead of a using toSaveVariableWithDot
[
https://issues.apache.org/jira/browse/TORQUE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14099776#comment-14099776
]
Thomas Fox commented on TORQUE-316:
---
The proposed patch solves the problem. Thanks a lot!
> saveMethods.vm has toSave.setNew instead of a using toSaveVariableWithDot
> -
>
> Key: TORQUE-316
> URL: https://issues.apache.org/jira/browse/TORQUE-316
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
>Reporter: Rob Decker
>Priority: Critical
>
> When I generate classes with
> torque.om.addSaveMethods=true
> torque.om.saveMethodsInDbObjects=true
> The dbobjects won't compile because the line toSave.setNew(false) is not a
> variable. I updated the saveMethods.vm template to fix the issue with this:
> diff
> torque-templates-4.0-new/org/apache/torque/templates/om/templates/general/saveMethods.vm
>
> torque-templates-4.0-orig/org/apache/torque/templates/om/templates/general/saveMethods.vm
> 65c65
> < ${toSaveVariableWithDot}setNew(false);
> ---
> > toSave.setNew(false);
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-317) BaseBean does generate fields for referencing objects
[
https://issues.apache.org/jira/browse/TORQUE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14099769#comment-14099769
]
Thomas Fox commented on TORQUE-317:
---
Problem can be reproduced with torque.om.complexObjectModel=false in the
torque-gen.properties
> BaseBean does generate fields for referencing objects
> -
>
> Key: TORQUE-317
> URL: https://issues.apache.org/jira/browse/TORQUE-317
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
> Environment: Centos 6.4, Java 8
>Reporter: Rob Decker
>Priority: Critical
>
> In the baseBean.vm template the field definitions for referenced objects
> mergepoints are present but the generated beans do not contain the fields.
> The methods do properly reference the fields but the code does not compile
> because the field declarations are missing.
> ## field definitions for referenced objects
> #if ($torqueGen.booleanOption("torque.om.complexObjectModel"))
> $torqueGen.mergepoint("fieldDefinitionsReferencedObjects")
> ##
> ## field definitions for referencing objects
> $torqueGen.mergepoint("fieldDefinitionsReferencingObjects")
> #end
> I am not familiar enough with templates to figure why it isn't working.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-316) saveMethods.vm has toSave.setNew instead of a using toSaveVariableWithDot
[
https://issues.apache.org/jira/browse/TORQUE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14099402#comment-14099402
]
Thomas Fox commented on TORQUE-316:
---
To reproduce the problem, torque.om.complexObjectModel=false must also be added
in the torque-gen properties file
> saveMethods.vm has toSave.setNew instead of a using toSaveVariableWithDot
> -
>
> Key: TORQUE-316
> URL: https://issues.apache.org/jira/browse/TORQUE-316
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
>Reporter: Rob Decker
>Priority: Critical
>
> When I generate classes with
> torque.om.addSaveMethods=true
> torque.om.saveMethodsInDbObjects=true
> The dbobjects won't compile because the line toSave.setNew(false) is not a
> variable. I updated the saveMethods.vm template to fix the issue with this:
> diff
> torque-templates-4.0-new/org/apache/torque/templates/om/templates/general/saveMethods.vm
>
> torque-templates-4.0-orig/org/apache/torque/templates/om/templates/general/saveMethods.vm
> 65c65
> < ${toSaveVariableWithDot}setNew(false);
> ---
> > toSave.setNew(false);
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
[jira] [Commented] (TORQUE-317) BaseBean does generate fields for referencing objects
[
https://issues.apache.org/jira/browse/TORQUE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14099378#comment-14099378
]
Thomas Fox commented on TORQUE-317:
---
I cannot reproduce the described behaviour.
I have enabled the beans in the torque test project and it is working (as
expected, as the beans profile was tested on release time).
To find the error, would you mind to check out the torque 4.0 test project at
http://svn.apache.org/viewvc/db/torque/torque4/tags/torque-4.0/torque-test/
and run
mvn -PderbyEmbedded,beans clean test
to see whether that works for you ?
E.g. sources for generated beans can be found in
target/generated-sources/org/apache/torque/test/bean/BaseAuthorBean.java (with
the collBookBeans field) and
target/generated-sources/org/apache/torque/test/bean/BaseBookBean.java (with
the aAuthorBean field)
Another idea would be to post the generator settings here, perhaps these cause
the error.
> BaseBean does generate fields for referencing objects
> -
>
> Key: TORQUE-317
> URL: https://issues.apache.org/jira/browse/TORQUE-317
> Project: Torque
> Issue Type: Bug
> Components: Templates
>Affects Versions: 4.0
> Environment: Centos 6.4, Java 8
>Reporter: Rob Decker
>Priority: Critical
>
> In the baseBean.vm template the field definitions for referenced objects
> mergepoints are present but the generated beans do not contain the fields.
> The methods do properly reference the fields but the code does not compile
> because the field declarations are missing.
> ## field definitions for referenced objects
> #if ($torqueGen.booleanOption("torque.om.complexObjectModel"))
> $torqueGen.mergepoint("fieldDefinitionsReferencedObjects")
> ##
> ## field definitions for referencing objects
> $torqueGen.mergepoint("fieldDefinitionsReferencingObjects")
> #end
> I am not familiar enough with templates to figure why it isn't working.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
