[Twisted-Python] enterprise.row

[Justin Ryan]

Dave,

Thanks for your response / comments..

> I think your diagnosis is correct. The current t.e code does not handle
> default values in the database schema, afaik. Given that, and the fact
> that the reflector wants to cache rows by primary keys, it can't support
> leaving primary keys unset before you create a new row.

I'm working on a patch that may allow this for key columns..

> 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..

> 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
supplied by the database could be kept in rowColumns.  You could then
set a value to allow or disallow setting of key columns with a default
value provided by the database.  This would prevent twisted from
encountering errors, so long as you define your schema correctly. 
Additionally, it would be better for referential integrity's sake..

Anyway, I'd appreciate any comments on my ideas.  I'm evaluating
twisted, including t.e.row, as part of a proposal to migrate our entire
python toolkit to soap or xml-rpc using twisted.  Getting t.e.row to
work in such a way that our large database (515 relations, including
sequences) will not be at risk will be an important part of this task.

Cheers,

-Justin