[storm] primary key autofilling

[Gustavo Niemeyer]

Hi Drew,

>>From my experiments, storm always tries to autofill primary key values
> when not set explicitly in the application.
> 
> First, is my observation correct?

It depends on what you mean by "autofill".  Storm will try to retrieve
the value used in the database if it stays unset, which means it won't
set this values manually in the application side.


> Second, if not correct, this is less than ideal behavior for an
> application I'm writing (on top of a legacy schema) where the primary
> key (a compound key = [uid:Integer, gid:Integer]) is in part managed
> by the schema itself via postgres triggers.    uid is set by the
> trigger, while gid is set explicitly in the application based on
> configuration.  Is there an easy way to bypass autofilling?

That's an interesting problem, which probably have a solution, but will
need some thinking.  Let me describe what's our requirements on the ORM
side, and then if you provide your requirements, we can sort out a
solution.

When an object is flushed to the database, and an insert happens, we have
an in-memory instance, and a row in the database, and they both represent
the same information.  Thus, we need a way to tell how to map the in-memory
instance into the row, so that if e.g. an update is done in the object, we
can update the row in the database.

Storm offers a few different ways to do that to the backends, but somehow
it has to become aware of the primary key used.  In Postgres 8.2, it's
possible to do a INSERT ... RETURNING, which is an excellent to implement
that, and one that we'll probably use in the near future.

Does this make sense?

-- 
Gustavo Niemeyer
http://niemeyer.net