[jira] Created: (TORQUE-116) property for object state
property for object state - Key: TORQUE-116 URL: https://issues.apache.org/jira/browse/TORQUE-116 Project: Torque Issue Type: Improvement Components: Generator, Runtime Environment: n/a Reporter: Thoralf Rickert Priority: Minor Sometimes it would be very helpful to know the state of an Object. Currently we have the states new and modified. Additionally I think there could be at least one state more. During initializing of the object (populateObject) the Base class calls some setters in the object. It would be nice to now that this set-methods are called during the initializing phase of the object to change the behavior of the method. The populateObject method could set an internal method isPopulating at the beginning of the process to true. And at the end it should set this variable to false. Then someone could check that variable state. Another situation would be save in an threaded and not-thread-safe-environment. This work for this is minimal. We need only a change in the templates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-85) setOffset(int) in Criteria should be setOffset(long)
setOffset(int) in Criteria should be setOffset(long) Key: TORQUE-85 URL: https://issues.apache.org/jira/browse/TORQUE-85 Project: Torque Issue Type: Improvement Components: Runtime Reporter: Thoralf Rickert Priority: Minor The Criteria.setOffset() method should accept long instead of int as the parameter value to allow an offset above 2 billion. Of course it's not recommended to have such Criteria's but it should be possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-75) Map XML column informations to the generated Objects
Map XML column informations to the generated Objects Key: TORQUE-75 URL: http://issues.apache.org/jira/browse/TORQUE-75 Project: Torque Issue Type: Improvement Components: Generator Reporter: Thoralf Rickert There is a small leakage of informations between XML definition and the generated Object. For example if you define a column as required=true it would be good to get this information in the object. So there could be a method like isMandatory(COLUMNNAME). One application for this could be generic analyzing of objects before saving to avoid SQL exceptions. Other informations would be size, scale and description for example. Of course we could retrieve this informations from the database but this means that we have to communicate with the database and there could be database specific inconsistency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TORQUE-75) Map XML column informations to the generated Objects
[ http://issues.apache.org/jira/browse/TORQUE-75?page=comments#action_12458959 ] Thoralf Rickert commented on TORQUE-75: --- Okay, then is this improvement request obsolet. Sorry. Map XML column informations to the generated Objects Key: TORQUE-75 URL: http://issues.apache.org/jira/browse/TORQUE-75 Project: Torque Issue Type: Improvement Components: Generator Reporter: Thoralf Rickert There is a small leakage of informations between XML definition and the generated Object. For example if you define a column as required=true it would be good to get this information in the object. So there could be a method like isMandatory(COLUMNNAME). One application for this could be generic analyzing of objects before saving to avoid SQL exceptions. Other informations would be size, scale and description for example. Of course we could retrieve this informations from the database but this means that we have to communicate with the database and there could be database specific inconsistency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TORQUE-74) Targets sql and datasql can't find required files
[ http://issues.apache.org/jira/browse/TORQUE-74?page=comments#action_12456094 ] Thoralf Rickert commented on TORQUE-74: --- I think, the sqldb.map file is generated when you call the sql ant-task. But I don't know why this file is necessary for the datadump task because it contains the files that are needed for the insert-sql task. Targets sql and datasql can't find required files - Key: TORQUE-74 URL: http://issues.apache.org/jira/browse/TORQUE-74 Project: Torque Issue Type: Bug Components: Generator Affects Versions: 3.3 Environment: Windows XP, JDK 1.5 Reporter: Joerg Friedrich I like to create an sql file from an XML data file I dumped using the following sequence (%ANT_HOME% points to ant 1.6.4): CALL %ANT_HOME%\bin\ant -f build-torque.xml jdbc %1 %2 %3 mv .\src\schema\schema.xml .\src\schema\track-schema.xml CALL %ANT_HOME%\bin\ant -f build-torque.xml datadtd %1 %2 %3 CALL %ANT_HOME%\bin\ant -f build-torque.xml datadump %1 %2 %3 mv .\src\track-theUser-all-data.xml .\src\schema\track-data.xml (Yes, the moves are necessary since there are some precoded file names in build-torque.xml). The following error appears: --- Nested Exception --- java.io.FileNotFoundException: D:\torque-gen-3.3-RC1\src\sql\sqldb.map (Das System kann den angegebenen Pfad nicht finden) at java.io.FileInputStream.open(Native Method) I can't find the file anywhere in the source code (btw.: the source code links at http://www.apache.org/dyn/closer.cgi/db/torque/torque-3.3/source/torque-gen-3.3-src.zip are broken today). When I run the sql target, I get the following messages: at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) Caused by: org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'sql/base/firebird/table.vm' at org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource (ResourceManagerImpl.java:501) And last but not least, beside these little problems, thanks for the superb work, guys! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TORQUE-71) custom velocity renderer to have nicely trimmed generated code
[ http://issues.apache.org/jira/browse/TORQUE-71?page=all ]
Thoralf Rickert updated TORQUE-71:
--
Attachment: patch.txt
Okay, here is a first patch. I didn't test it, because I don't have a suitable
test environment. What I did was to change the TorqueDataModelTask class. I've
copied! the execute method from velocity-TexenTask class. Then I've changed the
TemplateLoader for FileResourceLoader and ClasspathResourceLoader with my own
loaders (which extends File- and ClasspathResourceLoader) and call the filter
method (it uses streams now).
I'm not sure if the code compiles and runs because the Task uses two different
StringUtils classes and I'm not sure, if I checked everything. AND I'm not sure
if the template loader has any problems with the template syntax (see
discussion in July). Please report any problems - I'll try to find the problem.
We use this filter here since last year in our own TemplateLoader which get's
the templates from a database - so I'm sure that it works in principle but
there could be one or more templates that has to be changed.
custom velocity renderer to have nicely trimmed generated code
--
Key: TORQUE-71
URL: http://issues.apache.org/jira/browse/TORQUE-71
Project: Torque
Issue Type: Improvement
Components: Generator
Reporter: Thoralf Rickert
Priority: Minor
Attachments: patch.txt
The current Torque templates have spaces and tabs in front of Velocity
commands (#foreach, #set, #end,...). The Velocity renderer puts this spaces
and tabs into the generated code - that is the reason why the code in
generated Base* class files looks sometimes a little bit ugly. If we remove
the leading spaces in front of Velocity commands we can avoid this problem.
My solution is to override the rendering method in
org.apache.velocity.texen.ant.TexenTask that Torque uses to render the
templates and replace the template loader with our own. Therefor we can
remove the leading spaces.
/**
* This method filters the template and replaces some
* unwanted characters. For example it removes leading
* spaces in front of velocity commands and replaces
* tabs with spaces to prevent bounces in different
* code editors with different tab-width-setting.
*/
protected byte[] filter(String template, String encoding) throws Exception {
StringReader stringReader = new StringReader(template);
LineNumberReader lineNumberReader = new LineNumberReader(stringReader);
String line = null;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
PrintStream ps = new PrintStream(baos,true,encoding);
while ((line = lineNumberReader.readLine()) != null) {
// remove leading spaces in front of velocity commands and comments
line = line.replaceAll(^\\s*#, #);
// replace tabs with spaces to prevent bounces in editors
line = line.replaceAll(\t,);
ps.println(line);
}
ps.flush();
ps.close();
return baos.toByteArray();
}
The only problem is, that this would generate an error if you use empty
statements in #if or #foreach commands, for example
#if (something)
#end
This would create an error in velocity's render engine if you remove the
leading spaces - because empty statements are not allowed in Velocity. But
this can be avoided by add a single new line:
#if (something)
#end
A patch for the current generator comes in the next days.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-71) custom velocity renderer to have nicely trimmed generated code
custom velocity renderer to have nicely trimmed generated code
--
Key: TORQUE-71
URL: http://issues.apache.org/jira/browse/TORQUE-71
Project: Torque
Issue Type: Improvement
Components: Generator
Reporter: Thoralf Rickert
Priority: Minor
The current Torque templates have spaces and tabs in front of Velocity commands
(#foreach, #set, #end,...). The Velocity renderer puts this spaces and tabs
into the generated code - that is the reason why the code in generated Base*
class files looks sometimes a little bit ugly. If we remove the leading spaces
in front of Velocity commands we can avoid this problem.
My solution is to override the rendering method in
org.apache.velocity.texen.ant.TexenTask that Torque uses to render the
templates and replace the template loader with our own. Therefor we can remove
the leading spaces.
/**
* This method filters the template and replaces some
* unwanted characters. For example it removes leading
* spaces in front of velocity commands and replaces
* tabs with spaces to prevent bounces in different
* code editors with different tab-width-setting.
*/
protected byte[] filter(String template, String encoding) throws Exception {
StringReader stringReader = new StringReader(template);
LineNumberReader lineNumberReader = new LineNumberReader(stringReader);
String line = null;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
PrintStream ps = new PrintStream(baos,true,encoding);
while ((line = lineNumberReader.readLine()) != null) {
// remove leading spaces in front of velocity commands and comments
line = line.replaceAll(^\\s*#, #);
// replace tabs with spaces to prevent bounces in editors
line = line.replaceAll(\t,);
ps.println(line);
}
ps.flush();
ps.close();
return baos.toByteArray();
}
The only problem is, that this would generate an error if you use empty
statements in #if or #foreach commands, for example
#if (something)
#end
This would create an error in velocity's render engine if you remove the
leading spaces - because empty statements are not allowed in Velocity. But this
can be avoided by add a single new line:
#if (something)
#end
A patch for the current generator comes in the next days.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-59) correctBooleans() overwrites complex boolean criteria
correctBooleans() overwrites complex boolean criteria
-
Key: TORQUE-59
URL: http://issues.apache.org/jira/browse/TORQUE-59
Project: Torque
Issue Type: Bug
Components: Runtime
Affects Versions: 3.2
Environment: MySQL 5
Reporter: Thoralf Rickert
If you have a table with a nullable boolean column:
column name=test type=booleanint size=1/
and create a criteria like this:
Criterion c1 = criteria.getNewCriterion(TEST, false, Criteria.EQUAL);
Criterion c2 = criteria.getNewCriterion(TEST, null, Criteria.ISNULL);
criteria.add(c1.or(c2));
then the createQueryString returns the correct toString() result with
...WHERE (TEST = 0 or TEST IS NULL) ...
but when you call doSelect(), it sends just TEST = 0 to the database.
The problem is in the generated correctBooleans(Criteria) method. It checks if
the Criteria contains one of the boolean column and replaces the criterion with
an int value. So, in the above situation it removes the Criteria.ISNULL
part...that is not expected.
.
if (criteria.containsKey(TEST))
{
Object possibleBoolean = criteria.get(TEST);
if (possibleBoolean instanceof Boolean)
{
criteria.add(TEST, ((Boolean) possibleBoolean).booleanValue() ?
1 : 0);
}
}
The only possible workaround is to use the integer value (0,1) in the criterion
(Criterion c1 = criteria.getNewCriterion(TEST, 0, Criteria.EQUAL) ). But this
is not expected, because it is database specific.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TORQUE-44) Column names in generated classes are uppercase
[
http://issues.apache.org/jira/browse/TORQUE-44?page=comments#action_12434608 ]
Thoralf Rickert commented on TORQUE-44:
---
I think, the uppercase table names was a bug. It looks like a copypaste error.
So, if you wish to have a switch, it should be the other way round - enable the
switch to have uppercase table names.
But I'm not sure if it is useful to have such a switch - we have a lot of them.
Where is the problem in your example? If you compare torque table name
constants with a database table cell content you can use methods to make the
constants uppercase (in SQL or in Java). Of course - you have to change your
code. But I think, you shouldn't use the internal Torque table name constants.
I think, they are just for generating appropriate SQL query statements.
Column names in generated classes are uppercase
---
Key: TORQUE-44
URL: http://issues.apache.org/jira/browse/TORQUE-44
Project: Torque
Issue Type: Bug
Components: Generator
Affects Versions: 3.1, 3.1.1, 3.2
Reporter: Thoralf Rickert
Assigned To: Thomas Fischer
Fix For: 3.2.1
Attachments: patch.txt
The generator creates constants for the column names in tables. The content
of this constants uses upper cases.
For example if you have a table like:
table name=address
column name=class javaName=aClass primaryKey=true
required=true size=2 type=CHAR/
column name=id primaryKey=true required=true size=30
type=VARCHAR/
column name=position primaryKey=true required=true
type=INTEGER/
column name=name1 size=50 type=VARCHAR/
column name=name2 size=50 type=VARCHAR/
column name=name3 size=50 type=VARCHAR/
column name=street size=50 type=VARCHAR/
column name=zipcode size=25 type=VARCHAR/
column name=city size=60 type=VARCHAR/
column name=phone size=40 type=VARCHAR/
column name=phone2 size=40 type=VARCHAR/
column name=country size=200 type=VARCHAR/
column name=state size=200 type=VARCHAR/
column name=fax size=40 type=VARCHAR/
column name=email size=150 type=VARCHAR/
/table
The generator creates in the corresponding BaseAddressPeer the following
constants.
...
static
{
CLASS = address.CLASS;
ID = address.ID;
POSITION = address.POSITION;
NAME1 = address.NAME1;
NAME2 = address.NAME2;
NAME3 = address.NAME3;
STREET = address.STREET;
ZIPCODE = address.ZIPCODE;
CITY = address.CITY;
PHONE = address.PHONE;
PHONE2 = address.PHONE2;
COUNTRY = address.COUNTRY;
STATE = address.STATE;
FAX = address.FAX;
EMAIL = address.EMAIL;
but this variables should be for example address.email.
The AddressMapBuilder.doBuild() method creates the same uppercase mapping:
public void doBuild() throws TorqueException {
...
dbMap.addTable(address);
TableMap tMap = dbMap.getTable(address);
tMap.setPrimaryKeyMethod(none);
tMap.addPrimaryKey(address.CLASS, );
tMap.addPrimaryKey(address.ID, );
tMap.addPrimaryKey(address.POSITION, new Integer(0) );
tMap.addColumn(address.NAME1, , 50 );
tMap.addColumn(address.NAME2, , 50 );
tMap.addColumn(address.NAME3, , 50 );
tMap.addColumn(address.STREET, , 50 );
tMap.addColumn(address.ZIPCODE, , 25 );
tMap.addColumn(address.CITY, , 60 );
tMap.addColumn(address.PHONE, , 40 );
tMap.addColumn(address.PHONE2, , 40 );
tMap.addColumn(address.COUNTRY, , 200 );
tMap.addColumn(address.STATE, , 200 );
tMap.addColumn(address.FAX, , 40 );
tMap.addColumn(address.EMAIL, , 150 );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-51) Wrong Link on Download Page
Wrong Link on Download Page --- Key: TORQUE-51 URL: http://issues.apache.org/jira/browse/TORQUE-51 Project: Torque Issue Type: Bug Reporter: Thoralf Rickert Priority: Trivial The is a wrong link on http://db.apache.org/torque/download.html The link to the web interface of SVN is not http:svn.apache.org/viewcvs/db/torque but http://svn.apache.org/viewcvs/db/torque -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TORQUE-49) Encoding will not be used in insert-sql if it is used in generation task
[ http://issues.apache.org/jira/browse/TORQUE-49?page=comments#action_12427744 ] Thoralf Rickert commented on TORQUE-49: --- Okay, but then is the sql output of torque incorrect because it is generated in the encoding of the xml schema. My platform encoding is cp1251 or ISO 8859-1 but the xml schema is in UTF-8. The generated sql output is still in UTF-8 and not converted to cp1251 or ISO 8859-1. If Torque should use the current platform encoding for the generated files the sql and om tasks are buggy. Both generate files in the encoding of the XML schema file. They mix the encoding of the XML file and the encoding of the Torque templates. I'Ve tried the following test: - Add a special ISO-8859-1 character (for example a german umlaut) in the Torque template (for example Peer.vm) - Add a special UTF-8 character (another umlaut) in the UTF-8 encoded XML schema (for example a table description) - Generate the Peers and Objects classes. The description of the table should be added to the classes comment - The generated Peer has a ISO-8859-1 character and a UTF-8 character. Of course this is a special condition because the torque templates are normally in english and all characters can be mapped to the ASCII encoding which is a subset of ISO-8859-1 and UTF-8. So you normally don't have problems with special characters. But the fact is that torque ignores the encoding of the XML file. It should check the encoding of the XML file and convert it to the platform encoding (or better to the Torque template encoding). I had a lot of fun in the last months with character encoding in Java IO. This isn't trivial if you don't use the current platform encoding. Unicode doesn't help if you read and write text from/to files and ignore the encoding of them. Encoding will not be used in insert-sql if it is used in generation task Key: TORQUE-49 URL: http://issues.apache.org/jira/browse/TORQUE-49 Project: Torque Issue Type: Bug Components: Generator Affects Versions: 3.2 Reporter: Thoralf Rickert Priority: Trivial My schema.xml is encoded in UTF-8 and torque generates a SQL file in UTF-8. But when I run insert-sql the TorqueSQLExec task decodes the file with the system encoding because it doesn't know that the SQL file was encoded in UTF-8. My current solution is to set the attribute encoding=UTF-8 in the torque-sql-exec task call in my build-torque.xml. But I think torque should know the encoding of the files that it generates. It could be set (for example) in the sqldb.map file or by using special filename extension like .utf8.sql -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-49) Encoding will not be used in insert-sql if it is used in generation task
Encoding will not be used in insert-sql if it is used in generation task Key: TORQUE-49 URL: http://issues.apache.org/jira/browse/TORQUE-49 Project: Torque Issue Type: Bug Components: Generator Reporter: Thoralf Rickert Priority: Trivial My schema.xml is encoded in UTF-8 and torque generates a SQL file in UTF-8. But when I run insert-sql the TorqueSQLExec task decodes the file with the system encoding because it doesn't know that the SQL file was encoded in UTF-8. My current solution is to set the attribute encoding=UTF-8 in the torque-sql-exec task call in my build-torque.xml. But I think torque should know the encoding of the files that it generates. It could be set (for example) in the sqldb.map file or by using special filename extension like .utf8.sql -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TORQUE-49) Encoding will not be used in insert-sql if it is used in generation task
[ http://issues.apache.org/jira/browse/TORQUE-49?page=all ] Thoralf Rickert updated TORQUE-49: -- Affects Version/s: 3.2 Encoding will not be used in insert-sql if it is used in generation task Key: TORQUE-49 URL: http://issues.apache.org/jira/browse/TORQUE-49 Project: Torque Issue Type: Bug Components: Generator Affects Versions: 3.2 Reporter: Thoralf Rickert Priority: Trivial My schema.xml is encoded in UTF-8 and torque generates a SQL file in UTF-8. But when I run insert-sql the TorqueSQLExec task decodes the file with the system encoding because it doesn't know that the SQL file was encoded in UTF-8. My current solution is to set the attribute encoding=UTF-8 in the torque-sql-exec task call in my build-torque.xml. But I think torque should know the encoding of the files that it generates. It could be set (for example) in the sqldb.map file or by using special filename extension like .utf8.sql -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TORQUE-39) Wrong database name in generated XML schema with jdbc task
[ http://issues.apache.org/jira/browse/TORQUE-39?page=comments#action_12421539 ] Thoralf Rickert commented on TORQUE-39: --- Is it a big problem to hand over a property like torque.databaseName to the task or to parse the property torque.database.url? Wrong database name in generated XML schema with jdbc task -- Key: TORQUE-39 URL: http://issues.apache.org/jira/browse/TORQUE-39 Project: Torque Issue Type: Bug Components: Generator Affects Versions: 3.2 Reporter: Thoralf Rickert In org.apache.torque.task.TorqueJDBCTransformTask#generateXML() is a bug in line 196. 195:databaseNode = doc.createElement(database); 196:databaseNode.setAttribute(name, dbUser); This would generate a wrong XML schema database name=dbUser instead of database name=databaseName... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-44) Column names in generated classes are uppercase
Column names in generated classes are uppercase
---
Key: TORQUE-44
URL: http://issues.apache.org/jira/browse/TORQUE-44
Project: Torque
Issue Type: Bug
Components: Generator
Reporter: Thoralf Rickert
Attachments: patch.txt
The generator creates constants for the column names in tables. The content of
this constants uses upper cases.
For example if you have a table like:
table name=address
column name=class javaName=aClass primaryKey=true
required=true size=2 type=CHAR/
column name=id primaryKey=true required=true size=30
type=VARCHAR/
column name=position primaryKey=true required=true
type=INTEGER/
column name=name1 size=50 type=VARCHAR/
column name=name2 size=50 type=VARCHAR/
column name=name3 size=50 type=VARCHAR/
column name=street size=50 type=VARCHAR/
column name=zipcode size=25 type=VARCHAR/
column name=city size=60 type=VARCHAR/
column name=phone size=40 type=VARCHAR/
column name=phone2 size=40 type=VARCHAR/
column name=country size=200 type=VARCHAR/
column name=state size=200 type=VARCHAR/
column name=fax size=40 type=VARCHAR/
column name=email size=150 type=VARCHAR/
/table
The generator creates in the corresponding BaseAddressPeer the following
constants.
...
static
{
CLASS = address.CLASS;
ID = address.ID;
POSITION = address.POSITION;
NAME1 = address.NAME1;
NAME2 = address.NAME2;
NAME3 = address.NAME3;
STREET = address.STREET;
ZIPCODE = address.ZIPCODE;
CITY = address.CITY;
PHONE = address.PHONE;
PHONE2 = address.PHONE2;
COUNTRY = address.COUNTRY;
STATE = address.STATE;
FAX = address.FAX;
EMAIL = address.EMAIL;
but this variables should be for example address.email.
The AddressMapBuilder.doBuild() method creates the same uppercase mapping:
public void doBuild() throws TorqueException {
...
dbMap.addTable(address);
TableMap tMap = dbMap.getTable(address);
tMap.setPrimaryKeyMethod(none);
tMap.addPrimaryKey(address.CLASS, );
tMap.addPrimaryKey(address.ID, );
tMap.addPrimaryKey(address.POSITION, new Integer(0) );
tMap.addColumn(address.NAME1, , 50 );
tMap.addColumn(address.NAME2, , 50 );
tMap.addColumn(address.NAME3, , 50 );
tMap.addColumn(address.STREET, , 50 );
tMap.addColumn(address.ZIPCODE, , 25 );
tMap.addColumn(address.CITY, , 60 );
tMap.addColumn(address.PHONE, , 40 );
tMap.addColumn(address.PHONE2, , 40 );
tMap.addColumn(address.COUNTRY, , 200 );
tMap.addColumn(address.STATE, , 200 );
tMap.addColumn(address.FAX, , 40 );
tMap.addColumn(address.EMAIL, , 150 );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TORQUE-44) Column names in generated classes are uppercase
[ http://issues.apache.org/jira/browse/TORQUE-44?page=all ]
Thoralf Rickert updated TORQUE-44:
--
Attachment: patch.txt
The problem is that the generator uses the variable
$cup=$col.Name.toUpperCase() for the name of the constant and for the content
of it. The patch changes the Peer and the MapBuilder template. Hope it works.
Column names in generated classes are uppercase
---
Key: TORQUE-44
URL: http://issues.apache.org/jira/browse/TORQUE-44
Project: Torque
Issue Type: Bug
Components: Generator
Reporter: Thoralf Rickert
Attachments: patch.txt
The generator creates constants for the column names in tables. The content
of this constants uses upper cases.
For example if you have a table like:
table name=address
column name=class javaName=aClass primaryKey=true
required=true size=2 type=CHAR/
column name=id primaryKey=true required=true size=30
type=VARCHAR/
column name=position primaryKey=true required=true
type=INTEGER/
column name=name1 size=50 type=VARCHAR/
column name=name2 size=50 type=VARCHAR/
column name=name3 size=50 type=VARCHAR/
column name=street size=50 type=VARCHAR/
column name=zipcode size=25 type=VARCHAR/
column name=city size=60 type=VARCHAR/
column name=phone size=40 type=VARCHAR/
column name=phone2 size=40 type=VARCHAR/
column name=country size=200 type=VARCHAR/
column name=state size=200 type=VARCHAR/
column name=fax size=40 type=VARCHAR/
column name=email size=150 type=VARCHAR/
/table
The generator creates in the corresponding BaseAddressPeer the following
constants.
...
static
{
CLASS = address.CLASS;
ID = address.ID;
POSITION = address.POSITION;
NAME1 = address.NAME1;
NAME2 = address.NAME2;
NAME3 = address.NAME3;
STREET = address.STREET;
ZIPCODE = address.ZIPCODE;
CITY = address.CITY;
PHONE = address.PHONE;
PHONE2 = address.PHONE2;
COUNTRY = address.COUNTRY;
STATE = address.STATE;
FAX = address.FAX;
EMAIL = address.EMAIL;
but this variables should be for example address.email.
The AddressMapBuilder.doBuild() method creates the same uppercase mapping:
public void doBuild() throws TorqueException {
...
dbMap.addTable(address);
TableMap tMap = dbMap.getTable(address);
tMap.setPrimaryKeyMethod(none);
tMap.addPrimaryKey(address.CLASS, );
tMap.addPrimaryKey(address.ID, );
tMap.addPrimaryKey(address.POSITION, new Integer(0) );
tMap.addColumn(address.NAME1, , 50 );
tMap.addColumn(address.NAME2, , 50 );
tMap.addColumn(address.NAME3, , 50 );
tMap.addColumn(address.STREET, , 50 );
tMap.addColumn(address.ZIPCODE, , 25 );
tMap.addColumn(address.CITY, , 60 );
tMap.addColumn(address.PHONE, , 40 );
tMap.addColumn(address.PHONE2, , 40 );
tMap.addColumn(address.COUNTRY, , 200 );
tMap.addColumn(address.STATE, , 200 );
tMap.addColumn(address.FAX, , 40 );
tMap.addColumn(address.EMAIL, , 150 );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TORQUE-45) Generated SQL is in wrong order when dropping tables on table re-creation
[ http://issues.apache.org/jira/browse/TORQUE-45?page=comments#action_12421580 ] Thoralf Rickert commented on TORQUE-45: --- So how are tables with circular references dropped? I have this circular references problem in one of my schemes. And my solution is to drop the whole database. This isn't a problem in a development environment (it's faster) and later in a production environment you don't drop tables. Generated SQL is in wrong order when dropping tables on table re-creation - Key: TORQUE-45 URL: http://issues.apache.org/jira/browse/TORQUE-45 Project: Torque Issue Type: Bug Components: Generator Affects Versions: 3.2, 3.1.1 Environment: java 1.4.2, 1.5. Solaris 10. Reporter: Joe Carter When the table creation SQL is re-run when the schema contains foreign keys, you will get referential integrity complaints. This is because the table drop order means that it tries to drop dependent tables first. To fix this, the drop statements should be before all the creates. They should also be in reverse order to the creates. A method to be able to obtain the tables in reverse order will be needed to allow the templates to be modified to fix this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TORQUE-40) jdbc task fails on sybase database (schema is set)
[
http://issues.apache.org/jira/browse/TORQUE-40?page=comments#action_12420568 ]
Thoralf Rickert commented on TORQUE-40:
---
You have to set
torque.database.schema = dbo
in the properties to avoid this problem.
Thanks to Andras Balogh.
I think, this bug is fixed.
jdbc task fails on sybase database (schema is set)
--
Key: TORQUE-40
URL: http://issues.apache.org/jira/browse/TORQUE-40
Project: Torque
Type: Bug
Components: Generator
Versions: 3.2.1
Environment: Sybase ASE 12.5
jConnect for JDBC 2.0 v5.5 Build 25137 or v6.05 Build 25828
Java Tds Server Classes v5.5 Build 25138 or v6.0 Build 25828
Reporter: Thoralf Rickert
The Sybase JDBC driver doesn't expect a parameter for databaseSchema in
DatabaseMetaData.getTables(String catalog, String schemaPattern, String
tableNamePattern, String[] types)
DatabaseMetaData.getColumns(String catalog, String schemaPattern, String
tableNamePattern, String columnNamePattern)
DatabaseMetaData.getPrimaryKeys(String catalog, String schema, String table)
DatabaseMetaData.getImportedKeys(String catalog, String schema, String table)
If it is set to something else than null the methods return nothing. So
please add the following fix (pseudo code):
public void execute() throws BuildException
{
if (config(torque.database.type).equals(sybase))
{
dbSchema = null;
}
...
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TORQUE-40) jdbc task fails on sybase database (schema is set)
[ http://issues.apache.org/jira/browse/TORQUE-40?page=all ]
Thoralf Rickert resolved TORQUE-40:
---
Resolution: Won't Fix
See my previous comment. torque.database.schema must be set to dbo.
jdbc task fails on sybase database (schema is set)
--
Key: TORQUE-40
URL: http://issues.apache.org/jira/browse/TORQUE-40
Project: Torque
Type: Bug
Components: Generator
Versions: 3.2.1
Environment: Sybase ASE 12.5
jConnect for JDBC 2.0 v5.5 Build 25137 or v6.05 Build 25828
Java Tds Server Classes v5.5 Build 25138 or v6.0 Build 25828
Reporter: Thoralf Rickert
The Sybase JDBC driver doesn't expect a parameter for databaseSchema in
DatabaseMetaData.getTables(String catalog, String schemaPattern, String
tableNamePattern, String[] types)
DatabaseMetaData.getColumns(String catalog, String schemaPattern, String
tableNamePattern, String columnNamePattern)
DatabaseMetaData.getPrimaryKeys(String catalog, String schema, String table)
DatabaseMetaData.getImportedKeys(String catalog, String schema, String table)
If it is set to something else than null the methods return nothing. So
please add the following fix (pseudo code):
public void execute() throws BuildException
{
if (config(torque.database.type).equals(sybase))
{
dbSchema = null;
}
...
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TORQUE-27) Need ability to pass global user-configurable platform-specific hints to templates
[
http://issues.apache.org/jira/browse/TORQUE-27?page=comments#action_12420575 ]
Thoralf Rickert commented on TORQUE-27:
---
The proposal to create application specific custom templates isn't flexible. If
you upgrade torque, you've to upgrade and change your templates again. When you
don't do this once a year - you've forgotten, what you did with the templates.
If you use a script to change the generated code, you've to change this script
too. I think one of the main goals of torque should be to have static templates
that the user doesn't have to change.
The table type hint in this bug relates to the used storage engine in the
database tables. I think mysql isn't the only database that supports more than
one storage engine (this will be a key feature of future databases). So this
should be an optional table specific property with a default value for the
database. Of course, I'm using INNODB too and I'm using application specific
templates because of that.
On the other hand it would be useful to have such hints to add database, table
or column specific hints or features to the database schema (for example
charset encoding, mime-types, auto-increment start values, unsigned values and
so on). I think this could be in the template properties in the torque
properties but this seems to be unusual - especially if you have to set column
hints. It looks for me as a quick hack.
I think it would be better to add a new attribute to the xml tags database,
table and column (maybe other too). The value of this attribute can be
added to the generated sql output (just a plain pass thru without parsing).
Need ability to pass global user-configurable platform-specific hints to
templates
--
Key: TORQUE-27
URL: http://issues.apache.org/jira/browse/TORQUE-27
Project: Torque
Type: Improvement
Components: Generator
Versions: 3.2
Environment: Fedora Core 5 Linux, Sun JDK1.4.2_08.
Reporter: Adrian Price
Priority: Minor
It would be useful to provide a generic mechanism to enable the user to pass
global platform-specific hints to templates. For example, for MySQL it is
desirable to explicitly specify the type of table to be created, e.g., CREATE
TABLE foo (...) Type = InnoDB. Such global hints could then be specified by
the user through platform specific properties or property files, as in:
platform.properties:
mysql.table.hint=Type = InnoDB.
A matching table.vm template might look something like:
# ---
# $table.Name
# ---
$generator.parse($basepath/drop.vm, , table, $tbl)
CREATE TABLE $table.Name
(
etc...
) $platform.getProperty('mysql.table.hint');
Without such a capability it is necessary to hard-code the required
customizations into the templates, which is a rather inflexible and
inconvenient way of doing it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-43) retrieveByPK uses name instead of javaName
retrieveByPK uses name instead of javaName -- Key: TORQUE-43 URL: http://issues.apache.org/jira/browse/TORQUE-43 Project: Torque Type: Bug Components: Generator Versions: 3.2.1 Reporter: Thoralf Rickert Priority: Minor If you have a column definition like: column name=class javaName=aClass primaryKey=true required=true size=30 type=VARCHAR/ the generator creates retrieveByPK method with a parameter called class instead of aClass. This is unexpected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TORQUE-43) retrieveByPK uses name instead of javaName
[ http://issues.apache.org/jira/browse/TORQUE-43?page=all ] Thoralf Rickert updated TORQUE-43: -- Attachment: patch.txt This is a patch for this bug in Peer.vm retrieveByPK uses name instead of javaName -- Key: TORQUE-43 URL: http://issues.apache.org/jira/browse/TORQUE-43 Project: Torque Type: Bug Components: Generator Versions: 3.2.1 Reporter: Thoralf Rickert Priority: Minor Attachments: patch.txt If you have a column definition like: column name=class javaName=aClass primaryKey=true required=true size=30 type=VARCHAR/ the generator creates retrieveByPK method with a parameter called class instead of aClass. This is unexpected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-38) Wrong Default Setting for torque.enableJava5Features on website
Wrong Default Setting for torque.enableJava5Features on website --- Key: TORQUE-38 URL: http://issues.apache.org/jira/browse/TORQUE-38 Project: Torque Type: Bug Components: Documentation Reporter: Thoralf Rickert Priority: Trivial On the site http://db.apache.org/torque/releases/torque-3.2/generator/properties-reference.html is a bug in the documentation for the torque.enableJava5Features property. The default should been false and not Bean. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TORQUE-38) Wrong Default Setting for torque.enableJava5Features on website
[ http://issues.apache.org/jira/browse/TORQUE-38?page=all ] Thoralf Rickert updated TORQUE-38: -- Description: On the site http://db.apache.org/torque/releases/torque-3.2/generator/properties-reference.html is a bug in the documentation for the torque.enableJava5Features property. The default should be false and not Bean. (was: On the site http://db.apache.org/torque/releases/torque-3.2/generator/properties-reference.html is a bug in the documentation for the torque.enableJava5Features property. The default should been false and not Bean.) Wrong Default Setting for torque.enableJava5Features on website --- Key: TORQUE-38 URL: http://issues.apache.org/jira/browse/TORQUE-38 Project: Torque Type: Bug Components: Documentation Reporter: Thoralf Rickert Priority: Trivial On the site http://db.apache.org/torque/releases/torque-3.2/generator/properties-reference.html is a bug in the documentation for the torque.enableJava5Features property. The default should be false and not Bean. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TORQUE-31) complete generic type compatible API
[ http://issues.apache.org/jira/browse/TORQUE-31?page=all ]
Thoralf Rickert updated TORQUE-31:
--
Attachment: TORQUE-31.patch
Okay, this are the changes for the Peer.vm to be a little bit more generic type
compatible.
complete generic type compatible API
Key: TORQUE-31
URL: http://issues.apache.org/jira/browse/TORQUE-31
Project: Torque
Type: Improvement
Components: Generator
Versions: 3.2.1
Reporter: Thoralf Rickert
Priority: Trivial
Attachments: TORQUE-31.patch
If the generator creates Java5 compatible methods then there are some methods
from BasePeer that are not wrapped. This includes for example the execute*()
methods. If we wrap them in the generated classes the API looks a little bit
better.
Currently there is just one easy solution in my mind - wrap this methods in
the generated Base classes. For example:
public class BaseTablePeer extends BasePeer {
public static ListRecord executeQuery(String queryString) throws
TorqueException {
return (ListRecord)super.executeQuery(queryString);
}
}
This means, that every public method in BasePeer should be wrapped in the
generated class. I know, this is a lot and results in bigger classes and some
synchronization problems, if the API of BasePeer is changed. But I think,
it's easy to create.
I'll create a patch for that next week.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-31) complete generic type compatible API
complete generic type compatible API
Key: TORQUE-31
URL: http://issues.apache.org/jira/browse/TORQUE-31
Project: Torque
Type: Improvement
Components: Generator
Versions: 3.2.1
Reporter: Thoralf Rickert
Priority: Trivial
If the generator creates Java5 compatible methods then there are some methods
from BasePeer that are not wrapped. This includes for example the execute*()
methods. If we wrap them in the generated classes the API looks a little bit
better.
Currently there is just one easy solution in my mind - wrap this methods in the
generated Base classes. For example:
public class BaseTablePeer extends BasePeer {
public static ListRecord executeQuery(String queryString) throws
TorqueException {
return (ListRecord)super.executeQuery(queryString);
}
}
This means, that every public method in BasePeer should be wrapped in the
generated class. I know, this is a lot and results in bigger classes and some
synchronization problems, if the API of BasePeer is changed. But I think, it's
easy to create.
I'll create a patch for that next week.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TORQUE-23) DeepCopy
DeepCopy
Key: TORQUE-23
URL: http://issues.apache.org/jira/browse/TORQUE-23
Project: Torque
Type: New Feature
Components: Generator
Reporter: Thoralf Rickert
Priority: Minor
I've a small problem with the copy() and copyInto() methods in the generated
Torque objects. I've tables with dependencies from other tables (for example a
table login which has a foreign key to a table address). I want to use the
BaseAddress.copy() method to copy the address object and save it. If I use this
method, it also loads and copies internally all logins which are linked to the
source address to the new address. So, it makes a deep copy.
If the object Address has many hundreds related objects of Login this deep
copy makes a lot that is sometimes not necessary. So, it's better to let the
user/programmer decide if there program should do a deep copy or not.
The best way would be, that there is a copy(boolean) method that should be
added during BaseAddress generation. I think, it's not very complicated to add
this feature. Here is my proposal:
1. add in Object.vm a new boolean parameter to copy() like this
public $table.JavaName copy(boolean deepcopy) throws TorqueException
{
return copyInto(new ${table.JavaName}(),deepcopy);
}
2. create two new downwards compatible methods copy() and copyInto()
public $table.JavaName copy() throws TorqueException
{
return copy(true);
}
protected $table.JavaName copyInto($table.JavaName copyObj) throws
TorqueException
{
return copyInto(copyObject, true);
}
3. add a new parameter deepcopy to the old copyInto() method and check that
variable before making the
deepcopy. I think, it's not necessary to submit that value recursivly to the
referers.
protected $table.JavaName copyInto($table.JavaName copyObj, boolean) throws
TorqueException
{
#if ($complexObjectModel)
if (deepcopy) {
#foreach ($fk in $table.Referrers)
...
#end
}
#end
}
Maybe I can create a patch for you.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TORQUE-23) DeepCopy
[ http://issues.apache.org/jira/browse/TORQUE-23?page=all ]
Thoralf Rickert updated TORQUE-23:
--
Attachment: patch.txt
Okay, this is a patch for the Object.vm generated with Eclipse. It creates a
strange (localized) path to the Object.vm resource. I've changed this in the
patchfile and hope that is correct.
Additionally I didn't add a public abstract copy(boolean) method, because
this could generate some errors with existing projects because it changes the
API.
DeepCopy
Key: TORQUE-23
URL: http://issues.apache.org/jira/browse/TORQUE-23
Project: Torque
Type: New Feature
Components: Generator
Reporter: Thoralf Rickert
Priority: Minor
Attachments: patch.txt
I've a small problem with the copy() and copyInto() methods in the generated
Torque objects. I've tables with dependencies from other tables (for example
a table login which has a foreign key to a table address). I want to use
the BaseAddress.copy() method to copy the address object and save it. If I
use this method, it also loads and copies internally all logins which are
linked to the source address to the new address. So, it makes a deep copy.
If the object Address has many hundreds related objects of Login this
deep copy makes a lot that is sometimes not necessary. So, it's better to let
the user/programmer decide if there program should do a deep copy or not.
The best way would be, that there is a copy(boolean) method that should be
added during BaseAddress generation. I think, it's not very complicated to
add this feature. Here is my proposal:
1. add in Object.vm a new boolean parameter to copy() like this
public $table.JavaName copy(boolean deepcopy) throws TorqueException
{
return copyInto(new ${table.JavaName}(),deepcopy);
}
2. create two new downwards compatible methods copy() and copyInto()
public $table.JavaName copy() throws TorqueException
{
return copy(true);
}
protected $table.JavaName copyInto($table.JavaName copyObj) throws
TorqueException
{
return copyInto(copyObject, true);
}
3. add a new parameter deepcopy to the old copyInto() method and check that
variable before making the
deepcopy. I think, it's not necessary to submit that value recursivly to
the referers.
protected $table.JavaName copyInto($table.JavaName copyObj, boolean)
throws TorqueException
{
#if ($complexObjectModel)
if (deepcopy) {
#foreach ($fk in $table.Referrers)
...
#end
}
#end
}
Maybe I can create a patch for you.
--
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]
