[Nitro] Og, adapting postgresql to reorgnaization
john at oxyliquit.de
Thu Feb 22 08:50:05 EST 2007
> 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.
Yeah, but overriding it entirely is not an option here since it'd
conflict with the mysql version... (If I'm getting you right here, I'm
better in reading code :P)
> 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.
[I guess need to have a look at that code to understand that part.]
> No - that's an issue across the board, regardless of ORM.
Allright, so I got this one right at least. :)
> 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.
I would like to stay with the current psql implementation (first
nextval() then just use that value). I don't see a reason to misuse a
transaction for that, as it'll make 4 instead of 2 'instructions'.
> 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.
I'm not sure we can make MySQL thread safe (as I think the standard table
type doesn't react on 'transaction' anyway). Maybe we put a ruby-level
synchronized around that part?
Feel the love
More information about the Nitro-general