[Twisted-Python] enterprise.row

[Dave Peticolas]

On Sun, 2003-04-06 at 14:21, Justin Ryan wrote:
> > What I have done with postgres is to generate the primay key using
> > the nextval function on the sequence used for the serial column, setting
> > the row object's primary key, and then inserting it. This makes the t.e
> > code happy and you often need to know the new key anyway.
> 
> This will work but imho is a bit silly and not generally the way that I
> expect a database application to work.  If I set the default value on a
> column, I shouldn't have to handle that in my code.  Additionally, if
> you have a large development team with a DBA who manages the DB schema,
> changing the default value for a column shouldn't require a db change
> _and_ a code change.. that's inefficient and bug prone..

Sure, I'm not saying it's the best way, just the way I've done it 
before.


> > It would be nice to make t.e allow for default values and db-generated
> > primary keys, but that code would almost certainly need to be 
> > per-database since different databases handle serial/autoincrement
> > columns differently.
> 
> I don't really see how allowing key columns to be ignored on an insert
> would be database specific..  Ideally, whether or not a default value is

I don't think I fully articulated my thoughts. Currently the 'reflector'
code caches the rows you create. So, ideally, if the database is going
to set default values on a new row, you'd like the reflector to update
the row object with whatever values the database chose to maintain
consistency between the row object and the database. I haven't
thought about it too closely, but it seems to me that there's no
way to implement that in a database-independent way, but maybe I'm
just missing something.

What do you think?

dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: </pipermail/twisted-python/attachments/20030407/0e14a623/attachment.sig>