Re: [SQLObject] Re: SQLObject

[Edmund L. <el...@in...>]

Steve Holden wrote:

>> 5. Your assertion that MySQL does not support transactions is out of
date,
>> since they can be supported by databases built from InnoDB tables, I
believe
>> (or have I imagined this?).

Be aware that InnoDB is not free for commercial use, unlike PostgreSQL,
Firebird, SAPDB, etc. If you use InnoDB in any product that the user must
pay you for, you must buy a commercial license.

Tacking on something that does transactions does not make MySQL transaction
safe. See
http://searchdatabase.techtarget.com/tip/1,289483,sid13_gci788645,00.html?FromTaxonomy

%2Fpr%2F284872


Ian Bicking wrote:

>I don't know.  I like single, simple primary keys.  They work well.  If
>the table is really so minimal that it can't stand to have an extra
>field for the id, then I suspect a SQLObject class is too heavy for it
>(like with the join tables).  Of course, when adapting to a pre-existing
>schema you might not have as many options.  Maybe it wouldn't be that
>hard to fudge it (maybe make the ID into a tuple), but SQLObject really
>expects for each object to have a single ID.

Composite keys are used an awful lot in any schema of moderate complexity,
and they are important (when used with foreign key constraints) for
enforcing relational integrity. If the aim is for SQLObject to support
complex projects, then composite key support would be pretty important.

...Edmund.