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 -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
