[Nitro] Og, adapting postgresql to reorgnaization

Judson Lester nyarly at gmail.com
Wed Feb 21 19:33:28 EST 2007

On 2/21/07, Jonathan Buch <john at oxyliquit.de> wrote:
> Hi,
> > I just sent George a patch to fix that issue.  Basically, the SQL for
> > inserts and updates is pulled out to a method in SqlStore, so that
> > Postgres overrides that.
> only the sql?  No way to override the implementation itself to provide
> more flexibility?

If'n you want to, you can override og_insert, og_update, og_delete, or
og_read (not entirely sure off the top of my head why that's not
og_select...) and change their behavior entirely.  But for MySQL the
only tweak is to writing one type, and Postgres needs insert_sql
updated.  Why autoincrements weren't part of the original spec, I'll
never know.

> > As a sidenote, I altered the last_insert_id so that it returns
> > currval(#{seq}) and explicitly put a nextval() in the insert_sql
> > method.  Which looks right to me...
> Which has the (assumed) disadvantage of not being 'thread safe'.
> Assume 2 connections to the database, inserting into the same table.
> When those inserts happen too close to each other it may be that
> the currval() returns the wrong value.  I see the same problem with
> the mysql adapter.  Is this a non-issue?

No - that's an issue across the board, regardless of ORM.  My thought
would be, on the DBs that support it, to wrap inserts in a
transaction, so that the currval/nextval (because the same thread-safe
issue applies to nextval) is consistent with the insert.
Alternatively, we could push the pk setting into insert_sql and use
the value calculated for the insert as the @pk value.  Sadly, I think
both of those solutions would work for postgres and neither
necessarily for MySQL.


More information about the Nitro-general mailing list