Matt & Thomas,
Thanks for the update and for the id-method-parameter work-around.
As for the portability vs. flexibility question, my general
impression is that one can use the the id broker for maximum
portability, but choosing the "native" id method should make the best
use of inherent db features.
Carl
On May 23, 2005, at 11:31 PM, Thomas Fischer wrote:
Hi,
It seems this problem was introduced in Torque 3.1.1. It should be
fixed in
the cvs version ("fixed" means that you do not have to insert
additional
parameters in your schema for id generation). Check out the cvs and
look at
the "building" section of http://db.apache.org/torque/developer-
guide.html
to do the build.
If you want a released version, the templates from Torque 3.1.0
should
also work. To replace only the templates, locate the directory
templates/sql/base/postgresql (this should be either in torque-
gen.jar or
in the directory structure of the generator, depending on whether you
downloaded the jar or the zip or the tar.gz version of the generator).
Remove the files in there, get the files from 3.1.0 in the same
directory
and put them in there.
Matt, thanks for the link provided. I have not seen this discussion
before.
I am not sure of the general direction to go, but there are two
opposing
interests:
- flexibility to use any id generation in postgresql
- portability to other databases
Perhaps a solution can be found which satisfies both, but not so
sure what
this could be.
Thomas
Matt Hughes <[EMAIL PROTECTED]> schrieb am 23.05.2005 22:29:58:
Carl Ludewig wrote:
I'm using Torque 3.1.1 and Postgresql and have run into a problem
related to this thread of discussion. Something seems to be wrong in
this version regarding primary keys and sequences.
I'm still using 3.1 because it works and I never bothered to
upgrade, so
the rest of this is in part rampant speculation.
From Torque 3.1 to Torque 3.1.1, the stuff to create PostgreSQL
sequences used by Torque has been removed. Instead, PostgreSQL is
used
to automatically generate sequences by setting the column type to
serial
instead of int, but this only happens when autoIncrement="true".
This thread on the dev list discusses it a bit:
http://nagoya.apache.org/eyebrowse/BrowseList?listName=torque-
[EMAIL PROTECTED]&by=thread&from=871983
If I set my table to use idMethod="native", then torque generates
sql
that refers to a non-existence sequence and I can't insert any rows.
Because of the number of options that have to be set, it seems to be
really easy to select a set which results in a non-working system.
If I add autoIncrement="true" to my primary key, then I get working
sql
and I can insert rows via psql. BUT I can't insert any rows via the
peer objects, because the generated Java code refers to a sequence
that
does not exist.
Try using id-method-param to tell Torque about the autogenerated
sequence, as suggested by Scott
(http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
apache.org&msgNo=4108):
<table name="category" idMethod="native">
<column name="category_id" required="true" autoIncrement="true"
primaryKey="true" type="INTEGER"/>
<column name="name" size="100" type="VARCHAR"/>
<id-method-parameter name="seqName"
value="CATEGORY_CATEGORY_ID_SEQ"/>
</table>
Use psql and '\ds' to find out what the generated sequences are
named.
--
Matt Hughes
+ [EMAIL PROTECTED]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
