[jira] Created: (TORQUE-70) Escape Text in DBOracle not correct when using columns of type NVARCHAR2
Escape Text in DBOracle not correct when using columns of type NVARCHAR2 Key: TORQUE-70 URL: http://issues.apache.org/jira/browse/TORQUE-70 Project: Torque Issue Type: Bug Components: Runtime Affects Versions: 3.3 Environment: Oracle 9 Reporter: Tobias Hilka The default escape string for DBOracle is '\'. This works fine for VARCHAR2 columns. This statement is correct in these cases: SELECT * FROM MYTABLE WHERE MYCOLUMN LIKE 'TEST\_%' ESCAPE '\' This escape string does not work for columns of type NVARCHAR2. Using this escape character brings up the following error: ORA-01425: escape character must be character string of length 1 In case of columns of type NVARCHAR2 the correct escape character is N'\'. So the query above has to be written as follows: SELECT * FROM MYTABLE WHERE MYCOLUMN LIKE 'TEST\_%' ESCAPE N'\' We need some kind of mechanism to switch the escape string depending on the column used in the like statement. The problem is that at this point of execution, we don't have column objects but just plain strings representing the column names. (SQLExpression.buildLike(...)) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Torque 4.0 plan
Hi! [] - Use Java 5 style generics and enumerations. One can use compiler settings to produce pre-1.5-executable class files. Oh yes. I will be glad to help on this topic. Another small topic is my suggestion some months ago (July, 10.) to replace the ant velocity render task with our own velocity render task to remove leading spaces in front of velocity statements (__#foreach ...). Therefore we have to rewrite some lines in org.apache.velocity.texen.ant.TexenTask which we extend. This works here for my XHTML generation very good. Maybe there are some other features that could be possible with our own velocity renderer. bye Thoralf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque 4.0 plan
Is there any chance we can make the Peer classes non-static? Currently it's hard/impossible to override/extend these without making generator changes. Perhaps have some form of central registry to hold these classes so that they can be globally looked up but also replaced/extended if desired. The other suggestions are all very good - especially removing village. Thanks Joe On 29/11/06, Thomas Fischer [EMAIL PROTECTED] wrote: Now that the first Torque RC is outit is time to think about what we'd like to do as next version. Personally, I'd like to propose the following: - Next version should be 4.0. There can be major changes in the version, but the 'look and feel' should change as little as possibl. The idea would be that one can recompile one's Torque 3.2 or 3.3 project with the new Torque version and it should run with minor changes only. - Switch to Maven 2 as build system. Maven 2 has much better multiproject support than Maven 1, so building will be easier. - Simplify the repository structure: No svn externals any more. This would mean that all Torque components can only be released simultaneously, but as we have done so in the past anyway and compatibility problems would arise if we would'nt do so, this should not be problematic. - Use Java 5 style generics and enumerations. One can use compiler settings to produce pre-1.5-executable class files. - Kick out village. Village is bad. See the issue tracker for details. This would mean: create the sql to insert / update objects ourselves; do the Torque type / SQL type mapping of variables orselves; create objects directly from jdbc result sets. - Use the Criteria object only to hold query data and another object to hold update data. Criteria should not extend Hashtable any more nor sahould it implement the map interface, cause query data is not a Map in any sense (e.g. the same column names can appear more than once in a criteria) - Criterias should not be modified any more inside queries. Of one needs modification, one can copy the criteria. - Disentangle Query description and SQL creation code. In my eyes, it would be ideal to port the MVC paradigm to the SQL creation: The criteria is the model (what do I want to query), the view would cretae the SQL from the Query, and the controller would be the Peer class which executes the query. - Use a column object to hold the column name in the runtime instead of Strings. So one could remove all that distributed guesswork of what is the table name, do we have a schema name or not etc. This would also have the advantge that a String is clearly a value and not a column name. - Make the generator more generic. I'd like to turn the generator into a generiy code generation tool, which can be used to create all sort of code, not just database access code. I'm currently working on a proposal. Any opinions ? Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque 4.0 plan
Ups, I knew I forgot something on the list. This was in my mind but did not make it into the email. As you wrote, the problem of static methods is that you cannot override its behaviour. The beauty of static methods is that invocation is very simple. The idea would be to have a static Wrapper class, which holds a singleton of the class with the implementation, and which passes all its static calls to the implementation class. There would be a setter of the singleton in the static class, so the backing class would be exchangeable. So one can use the static class if simple invocation is wanted, and the implementation class if maximum flexibility is needed. Thomas [EMAIL PROTECTED] schrieb am 30.11.2006 11:58:25: Is there any chance we can make the Peer classes non-static? Currently it's hard/impossible to override/extend these without making generator changes. Perhaps have some form of central registry to hold these classes so that they can be globally looked up but also replaced/extended if desired. The other suggestions are all very good - especially removing village. Thanks Joe On 29/11/06, Thomas Fischer [EMAIL PROTECTED] wrote: Now that the first Torque RC is outit is time to think about what we'd like to do as next version. Personally, I'd like to propose the following: - Next version should be 4.0. There can be major changes in the version, but the 'look and feel' should change as little as possibl. The idea would be that one can recompile one's Torque 3.2 or 3.3 project with the new Torque version and it should run with minor changes only. - Switch to Maven 2 as build system. Maven 2 has much better multiproject support than Maven 1, so building will be easier. - Simplify the repository structure: No svn externals any more. This would mean that all Torque components can only be released simultaneously, but as we have done so in the past anyway and compatibility problems would arise if we would'nt do so, this should not be problematic. - Use Java 5 style generics and enumerations. One can use compiler settings to produce pre-1.5-executable class files. - Kick out village. Village is bad. See the issue tracker for details. This would mean: create the sql to insert / update objects ourselves; do the Torque type / SQL type mapping of variables orselves; create objects directly from jdbc result sets. - Use the Criteria object only to hold query data and another object to hold update data. Criteria should not extend Hashtable any more nor sahould it implement the map interface, cause query data is not a Map in any sense (e.g. the same column names can appear more than once in a criteria) - Criterias should not be modified any more inside queries. Of one needs modification, one can copy the criteria. - Disentangle Query description and SQL creation code. In my eyes, it would be ideal to port the MVC paradigm to the SQL creation: The criteria is the model (what do I want to query), the view would cretae the SQL from the Query, and the controller would be the Peer class which executes the query. - Use a column object to hold the column name in the runtime instead of Strings. So one could remove all that distributed guesswork of what is the table name, do we have a schema name or not etc. This would also have the advantge that a String is clearly a value and not a column name. - Make the generator more generic. I'd like to turn the generator into a generiy code generation tool, which can be used to create all sort of code, not just database access code. I'm currently working on a proposal. Any opinions ? Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Torque 4.0 plan
Thomas Fischer said: Now that the first Torque RC is outit is time to think about what we'd like to do as next version. Personally, I'd like to propose the following: Can't complain about that list. Only +0 items I'd list would be on the Maven 2 conversion and the generic generator. - Switch to Maven 2 as build system. Maven 2 has much better multiproject support than Maven 1, so building will be easier. My +0 for Maven 2 is based on the little bit I dug into it for the add-on stuff. It seemed to add a lot of complication and extra more effort to do thing outside the Maven 2 norm that was fairly easy in 1. IMHO, build systems should take a minimum of time away from your development time, not become a subproject of it's own. But to be fair, it could be I just didn't take the time to learn it well enough. But if someone else is doing the work ;) who am I to complain...lol - Make the generator more generic. I'd like to turn the generator into a generic code generation tool I'm +0 on the idea of the generic generator. I can see the worth in this, but I'm not sure it's a core Torque thing. It seems like this should be like Torque and Turbine, some of the ground work layed here but with a plan to split it off into a separate project. Plus, is this competing with Velocity/Texen? None of this is a show stopper, just thoughts for fine tuning the proposal. Here's some idea's I'll throw in the ring: Better support for non-record type queries. I.e., the stuff people do with executeQuery / Village Records. Queries of this type that come to mind are: - Optimized Join queries that return data from multiple tables (for creating master lists). - Queries with functions. To support this and also assist in the Village exorcism, I'd propose making the BaseObject an actual storage implimentation, like Village Record or ResultsSet. Internally the data would be stored as objects in OrderedMap with the getBy/setBy methods being the BaseObject access points. This would allow executeQuery to return a list of BaseObject records. Additionally, the generated record objects could make use of this new base class to support things like isNull() on primitives. We could also use this to track modified and unmodified column values, which would be very useful (e.g. updating tables without primary keys). Take a serious look at DDLUtils integration, and maybe do a little encouraging to get that project to do a release/ Maven repo set up. Some stuff that may be V4.5 features but might be nice to start planning for: Add full support for views, since most of the common DBs support them. E.g., a way to define them in the DTD, support for creation, etc. Look at being able to generate object level views. E.g., I'm always creating wrapper objects that are based on subsets of data from two or more related tables, with access, load, and store methods. I'm thinking this would be a way to define business objects via XML and have them generated. Support for lazy record object population. Sometimes it's better to retrieve a set of partially filled objects (e.g. doing a master list), and only totally fill the object when needed. Adding an isLoaded option to the isNull, isModified, column level tracking would make this fairly easy. A GUID based idBroker method to autogenerate keys without needing access to a table. Duke CE Privacy Statement Please be advised that this e-mail and any files transmitted with it are confidential communication or may otherwise be privileged or confidential and are intended solely for the individual or entity to whom they are addressed. If you are not the intended recipient you may not rely on the contents of this email or any attachments, and we ask that you please not read, copy or retransmit this communication, but reply to the sender and destroy the email, its contents, and all copies thereof immediately. Any unauthorized dissemination, distribution or copying of this communication is strictly prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque 4.0 plan
Greg Monroe wrote: Additionally, the generated record objects could make use of this new base class to support things like isNull() on primitives. We could also use this to track modified and unmodified column values, which would be very useful (e.g. updating tables without primary keys). I'd throw primitives away completely. There is no advantage in keeping them. Especially with JDK 1.5. Add full support for views, since most of the common DBs support them. E.g., a way to define them in the DTD, support for creation, etc. +1 on this. This shouldn't be too difficult to handle. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Torque 4.0 plan
Thomas Vandahl said: Greg Monroe wrote: Additionally, the generated record objects could make use of this new base class to support things like isNull() on primitives. We could also use this to track modified and unmodified column values, which would be very useful (e.g. updating tables without primary keys). I'd throw primitives away completely. There is no advantage in keeping them. Especially with JDK 1.5. I think there's still benefit in having record objects with primitive get/set field access methods. They are like the static Peer methods, not the best way to do things, but they make coding easier. But the underlying storage could be Object based with conversion occuring in the generated field methods. Even with these, the underlying objects could still be access via the getBy/setBy methods. Of course, there would be a slight performance hit since the conversion takes place each time the method is called rather than at population time. Duke CE Privacy Statement Please be advised that this e-mail and any files transmitted with it are confidential communication or may otherwise be privileged or confidential and are intended solely for the individual or entity to whom they are addressed. If you are not the intended recipient you may not rely on the contents of this email or any attachments, and we ask that you please not read, copy or retransmit this communication, but reply to the sender and destroy the email, its contents, and all copies thereof immediately. Any unauthorized dissemination, distribution or copying of this communication is strictly prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r481086 - /db/torque/site/trunk/xdocs/navigation.xml
Author: tfischer Date: Thu Nov 30 13:31:48 2006 New Revision: 481086 URL: http://svn.apache.org/viewvc?view=revrev=481086 Log: added a link to the torque 3.2 site in the navigation Modified: db/torque/site/trunk/xdocs/navigation.xml Modified: db/torque/site/trunk/xdocs/navigation.xml URL: http://svn.apache.org/viewvc/db/torque/site/trunk/xdocs/navigation.xml?view=diffrev=481086r1=481085r2=481086 == --- db/torque/site/trunk/xdocs/navigation.xml (original) +++ db/torque/site/trunk/xdocs/navigation.xml Thu Nov 30 13:31:48 2006 @@ -64,6 +64,7 @@ item name=Previous releases href=/documentation/previous-releases.html collapse=true !-- The following href attributes need to be absolute links, Otherwise they will not work in an archived version of the site. -- +item name=Torque 3.2 href=http://db.apache.org/torque/releases/torque-3.2/index.html; target=_blank/ item name=Torque 3.1.1 href=http://db.apache.org/torque/releases/torque-3.1.1/index.html; target=_blank/ item name=Torque 3.1 href=http://db.apache.org/torque/releases/torque-3.1/index.html; target=_blank/ /item - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Site redeployed
I just redeployed the site to remove an issue with the 3.2 site archive and to bring the updated tutorial online. If there are any issues, especially in the site archive, please let me know. Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque 4.0 plan
On Fri, 1 Dec 2006, Jonathan Purvis wrote: Hi, Everything about the Torque 4.0 plans sounds good to me, especially getting rid of Village. However this one won't work: - Use Java 5 style generics and enumerations. One can use compiler settings to produce pre-1.5-executable class files. The autoboxing in 1.5 of int to Integer uses Integer.valueOf(int), which doesn't exist in 1.4. Also, javac won't let you: $ javac -target 1.4 Generic.java javac: target release 1.4 conflicts with default source release 1.5 $ javac -target 1.4 -source 1.5 Generic.java javac: source release 1.5 requires target release 1.5 You are right, I was not aware of this. So what do we do ? I'd guess most people will use java 1.5 by the time the new release is ready (I do not think less than a year's development time is realistic), but I'm also sure there are some users who cannot use Java 1.5. Supporting 1.5 in the generator is the minimum option (we have that already), but my original idea was to port the runtime and the other stuff as well. I'd guess if we do not do it in the step towards 4.0 we'll never make that transition. I'm undecided. Any opinions ? Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Torque 4.0 plan
On Thu, 30 Nov 2006, Greg Monroe wrote:
...
- Switch to Maven 2 as build system. Maven 2 has much better
multiproject support than Maven 1, so building will be
easier.
My +0 for Maven 2 is based on the little bit I dug into it
for the add-on stuff. It seemed to add a lot of complication
and extra more effort to do thing outside the Maven 2 norm
that was fairly easy in 1. IMHO, build systems should take a
minimum of time away from your development time, not become
a subproject of it's own.
But to be fair, it could be I just didn't take the time to
learn it well enough. But if someone else is doing the work ;)
who am I to complain...lol
I'd volunteer to set it up. Maven 2 has a better multiproject support than
maven 1, so some stuff will also be easier. Also, it is much faster on
building.
if there is trouble, we can still decide what we do when we have a
prototype.
- Make the generator more generic. I'd like to turn the
generator into a generic code generation tool
I'm +0 on the idea of the generic generator. I can see the
worth in this, but I'm not sure it's a core Torque thing.
It seems like this should be like Torque and Turbine, some
of the ground work layed here but with a plan to split it
off into a separate project.
The generator is already quite a separate project which can be
used on its own. The only torque specific stuff now is the parsing of the
schema.xml and putting it into the database model. Ok, throw that out, and
nothing is left of the generator as it is now, but here my idea was a
replacement and not a slow migration. The torque specific stuff (no
java, but meta-information) can go into the templates.
Plus, is this competing with
Velocity/Texen?
Well, my idea would be to support velcocity, of course, but also other
templating languages like xslt, and also plain java. So it would be more
powerful than texen, but yes, you could call it competing if you like.
...
Here's some idea's I'll throw in the ring:
Better support for non-record type queries. I.e., the
stuff people do with executeQuery / Village Records. Queries
of this type that come to mind are:
- Optimized Join queries that return data from multiple
tables (for creating master lists).
you mean something like the DoSelectJoinXXX() queries ?
- Queries with functions.
+1
To support this and also assist in the Village exorcism,
I'd propose making the BaseObject an actual storage
implimentation, like Village Record or ResultsSet. Internally
the data would be stored as objects in OrderedMap with the
getBy/setBy methods being the BaseObject access points.
This would allow executeQuery to return a list of BaseObject
records.
Additionally, the generated record objects could make use
of this new base class to support things like isNull() on
primitives. We could also use this to track modified and
unmodified column values, which would be very useful (e.g.
updating tables without primary keys).
I'm note sure whether this is the best possible approach. I'd rather work
with a jdbc result set and generate a method that directly populates an
object from the jdbc result set. This has the advantage that you can rely
on type conversion of the jdbcDriver (getAsInt etc) and do not have the
trouble to store which type which object is. It is also faster and less
memory-consuming.
This can be achieved in two different ways. Thomas V's favorite is just
calling an abstract method in BasePeer which gets overridden in each
concrete peer and which is called for each row in the resultSet. something
like
ResultSet resultSet = doSelectSomething();
while(resultSet.next())
{
resultList.add(createObject(resultSet))
}
and the createObject() method would be generated for each peer.
My favourite is to use an ObjectCreator class, which would be called for
each row in a resultSet and create an object out of it. The concrete Peer
itself could be the Object creator.
The first has the advantage of being the simplest possible approach, the
second is more flexible (the method which does the selects and calls the
ObjectCreator could be used for custom object creators, which use the
values in the data row in any way they like)., and so provide a
replacement for the doSelectVollageRecords, which is uften used for
custom selects now.
Take a serious look at DDLUtils integration, and maybe do
a little encouraging to get that project to do a release/
Maven repo set up.
+1
Some stuff that may be V4.5 features but might be nice to
start planning for:
Add full support for views, since most of the common DBs
support them. E.g., a way to define them in the DTD,
support for creation, etc.
+1 (repeating myself)
Look at being able to generate object level views. E.g.,
I'm always creating wrapper objects that are based on
subsets of data from two or more related tables, with access,
load, and store methods. I'm thinking this would be a way
to define business objects via XML and have them
Re: Torque 4.0 plan
Personally I'd just have the singleton and ditch the static wrapper completely, however I recognise that having the wrapper would keep is closer to what exists already, so I'm not overly concerned. A method to get the singleton would make sense to match the set and would allow you to get an extended version of the back-end should that be available. Thanks Joe On 30/11/06, Thomas Fischer [EMAIL PROTECTED] wrote: Ups, I knew I forgot something on the list. This was in my mind but did not make it into the email. As you wrote, the problem of static methods is that you cannot override its behaviour. The beauty of static methods is that invocation is very simple. The idea would be to have a static Wrapper class, which holds a singleton of the class with the implementation, and which passes all its static calls to the implementation class. There would be a setter of the singleton in the static class, so the backing class would be exchangeable. So one can use the static class if simple invocation is wanted, and the implementation class if maximum flexibility is needed. Thomas [EMAIL PROTECTED] schrieb am 30.11.2006 11:58:25: Is there any chance we can make the Peer classes non-static? Currently it's hard/impossible to override/extend these without making generator changes. Perhaps have some form of central registry to hold these classes so that they can be globally looked up but also replaced/extended if desired. The other suggestions are all very good - especially removing village. Thanks Joe
Re: Torque 4.0 plan
Joe Carter [EMAIL PROTECTED] writes: Is there any chance we can make the Peer classes non-static? Currently it's hard/impossible to override/extend these without making generator changes. Perhaps have some form of central registry to hold these classes so that they can be globally looked up but also replaced/extended if desired. At that point you will need sort of a context object like all the other O/R mappers have. :-) The other suggestions are all very good - especially removing village. Definitely. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque 4.0 plan
Greg Monroe [EMAIL PROTECTED] writes: - Switch to Maven 2 as build system. Maven 2 has much better multiproject support than Maven 1, so building will be easier. My +0 for Maven 2 is based on the little bit I dug into it for the add-on stuff. It seemed to add a lot of complication and extra more effort to do thing outside the Maven 2 norm that was fairly easy in 1. IMHO, build systems should take a minimum of time away from your development time, not become a subproject of it's own. I'd *strongly* suggest thinking about the maven support. Maven changed from 1 to 2 completely (different POMs, different program name, different properties, different plugins, different docs) so people moving from m1 to m2 had to throw all their configs (project.xml, maven.xml, properties) away and rework them (most of the time from scratch). And the projects relying on m1 suddently find out that people no longer have the 'old' maven installed and complain about not being able to build the project. There is no guarantee that moving from m2 to m3 will not be the same thing. There *is* a simple solution: Provide basic project building with ant. ant stood the test of time quite nicely. Keep the maven (m1, m2) build optional but build your release archives with ant. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque 4.0 plan
Thomas Vandahl [EMAIL PROTECTED] writes: Greg Monroe wrote: Additionally, the generated record objects could make use of this new base class to support things like isNull() on primitives. We could also use this to track modified and unmodified column values, which would be very useful (e.g. updating tables without primary keys). I'd throw primitives away completely. There is no advantage in keeping them. Especially with JDK 1.5. You lose all the J2EE 1.4 people. J2EE will be (in the real world) on JDK 1.4 for a long time. There are tools like Retroweaver but throwing primitive support out is IMHO too early. Hibernate did and people still complain about it. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque 4.0 plan
Joe Carter [EMAIL PROTECTED] writes: Personally I'd just have the singleton and ditch the static wrapper completely, however I recognise that having the wrapper would keep is closer to what exists already, so I'm not overly concerned. A method to get the singleton would make sense to match the set and would allow you to get an extended version of the back-end should that be available. If you think about a singleton, please separate the singleton class and the implementation class (don't have the static getInstance() method and a possible private C'tor in the implementation). If you separate these, it is possible for projects using e.g. Spring to manage the classes through the framework. Even better, google for 'evil singleton' and read the first few links... Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
