Re: sequences and Postgresql

[prev] [thread] [next] [Date index for 2004/07/08]

On Wed, 7 Jul 2004, Takes Tea at Half Past Three wrote:
> >Interesting...
> >but with the NOT NULL in there CDBI won't leave it alone.
> 
> CDBI doesn't know anything about that NOT NULL. It's not querying my schema.

True -- its DBD::Pg that complains. That error just propagates back.
If you explicitly declare the sequence then you should be able to rely on 
the default and you don't need NOT NULL . Without the NOT NULL, I think 
the database would be able to take care of it. I'm not sure though...its 
still a primary key and CDBI won't let you rely on the database to fill 
in the value .

> >closely at the CDBI documentation is in fact what was specified.
> >Sigh. It still is non-optimal -- extra Perl code to run not to mention
> >extra round-trips to the database.  For what I'm doing I'm in a low
> >transaction-rate environment (my app isn't the only thing using the
> >database; there's a RADIUS server hammering away with authentication ,
> >authorization and accounting ) so I'm ok...and I guess in a extremely
> >high-volume system the overhead of CDBI is a problem. I haven't tried to
> >run priceline.com on Perl with CDBI ...though I understand amazon.com uses
> >HTML::Mason...
> 
> Perhaps you should mention this solution and why you think it's 
> suboptimal to the list. Maybe someone has a better idea.

I thought I had sent the respone to the list but in fact I didn't so I 
have gone back and resent it there.
As for suboptimal -- I made the case , such as it is, already.
I haven't time to measure the difference in performance but clearly there 
is a difference in running extra Perl code (_prepopulate_id and that in 
turn calls Ima::DBI eventually which calls DBI which goes to the 
database...and then all those layers back up) and database activity.
One user on a data entry system with a web i/f incurring one extra 
transaction is not going to see the difference. A busy e-commerce site 
with 5-10 transactions/second, yes.