Re: [SQLObject] Bug in foreign keys?

[Martin B. <bl...@fu...>]

On 12/26/05, Oleg Broytmann <ph...@ph...> wrote:
> On Wed, Dec 14, 2005 at 04:40:52PM -0500, Martin Blais wrote:
> > On 12/14/05, Oleg Broytmann <ph...@ph...> wrote:
> > >    Think one wants
> > > to create two tables that reference each other. It was impossible to =
do in
> > > SQLObject because SQLObject tried to create a table with all constrin=
ts...
> > > and databases return errors becuase the table to be created reference
> > > another table that hasn't been created yet.
> > >    So .createTable() machinery was changed to create tabes without
> > > constrinas and return necceessary ALTER TABLES command which you shou=
ld
> > > execute after table creation. Something like this:
> >
> > Is anyone keeping track of these important API changes somewhere?
> > Because if no-one is, the task to port 0.6-based apps to 0.7 will be a
> > perilous one.  Both of the bugs/changes required from this thread do
> > not generate warnings when upgrading.
> >
> > Why not make the default case nice (i.e. create the constraints by
> > default), and letting the user prevent the constraints creation from
> > being done when this is needed (e.g. with a keyword argument) ?
>
>    Well, I am ready to commit changes. SQLObject.createTable() got a new
> keyword, applyConstraints, True by default. So you do either
>
> MyTable1.createTable()
> MyTable2.createTable()
>
>    or
>
> constrints =3D MyTable1.createTable(applyConstraints=3DFalse)
> constrints +=3D MyTable2.createTable(applyConstraints=3DFalse)
>
> for constraint in constraints:
>    conn.query(constraint)
>
> Is it ok?

Thanks for the work Oleg!  :-)
But for your question the answer is "yes and no".

- "yes" it will do, in the sense that it will patch the problem.  I
have been rewriting my schemas "by hand" in the meantime, and since
SQLObject allows binding to already existing tables, it allows me
gradually remove it from my codebase, step-by-step, which is nice
because my app can keep working during the transition, and I can write
the constraints directly, with even more detail.

- and "no" it suppose won't completely really be ok, in the sense that
not using the special flag still opens up the possibiltiy for the race
condition, and IMHO this needs to be either documented with ten-foot
wide red-on-black blinking text somewhere, or maybe it should just not
be permitted, but I guess that depends on how much "looseness" and
coherency users are willing to accept when using an ORM.  At least the
default is to apply the constraints, that's a good choice IMO.


A more important question for me is, how much "stuff" should SQLObject
be allowed to do for the user?  What an ORM adds on top of just easing
access to SQL should be clearly delineated IMO and now I find that
sqlobject does a bit too much magic behind-the-scenes stuff for my
taste.   It's like programming C++: if you don't have a very good idea
what the compiler will do with your source, you can't really write
efficient code, you just can't.  Same with this: if I don't know
exactly most of what happens when I use sqlobject objects, I'm bound
to create terribly inefficient or buggy code-- my bugs, and the ORM's
bugs.  I used to be under the impression that SQLObject did a lot less
that it does.

cheers,