On Sun, Mar 03, 2002 at 05:04:12PM -0500, Bill Schneider wrote:
> I also had problems with PostgreSQL native sequences and Torque 3.0 dev, but
> my workaround took a slightly different approach: everything in the DB
> adapter actually works fine, except that it tries to use the wrong sequence
> name. So instead of modifying the DB adapters I modified the SQL-generation
> templates, to change the sequence name from the one PG creates for you, to a
> new one with the name the DB adapter expects. (I think I submitted a patch
> for this, which is related to another Torque/PostgreSQL problem: the
> autogenerated DROP TABLE statements don't drop the auto-generated sequences
> that PostgreSQL creates, which much be dropped *separately* from the table)
I create and drop sequences independently of the table, partly an oracle
carry-over, but I also like to be explicit when possible. To make it
work I set the sequence name for the table using the id-method-parameter
tag in the table schema, example:
<table name="preview" idMethod="native">
...
<id-method-parameter value="preview_id_seq"/>
</table>
Keep in mind that I've never used the Torque table creation stuff,
my database already existed.
> PostgreSQL "serial" columns are really a hybrid of the sequence and
> auto-increment approach: they're like autoincrement columns that use
> sequences under the hood.
[some sql snipped]
> You don't have to specify foo_id on INSERT, because it defaults to "nextval
> ...". This is really the key distinction between Torque's "sequence" and
> "autoincrement" type: does Torque need to specify the ID when I insert, or
> is that done by the db? The fact that serial columns happen to be
> implemented with sequences is irrelevant as far as Torque is concerned
> (aside from the get-current-value SQL snippet).
I didn't quite understanding how torque viewed a sequence vs an auto
increment primary key, you've clarified that point for me. While I don't
use the serial type, I do use the default nextval in the table definition.
Makes me wonder why I couldn't get it working the first time, I'll have
to try it again and see why it wasn't behaving correctly.
> In PostgreSQL you get the ID of the last row inserted with
> currval('sequence_name'). That's probably why you thought currval/nextval
> were backwards, as was my initial thought as well--the nextval is taken care
> of for you by the column default. And everything works fine as long as the
> sequence name Torque looks for is actually there.
According to the docs in DBPostgres something is backwards. The function
getIDMethodSQL is documented as returning "SQL to retreive the next
database key", but it calls currval. The getSequenceSql method uses
nextval but is documented as "Returns the last auto-increment key."
Because I don't know under which case these methods are used and it
wasn't working for me I assumed the documentation was correct.
Steve Stock
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
