Re: [SQLObject] ANN: SQLObject 0.3

[Ian B. <ia...@co...>]

On Wed, 2003-04-09 at 02:52, Bud P.Bruegger wrote:
> * createTable(ifNotExists=True):
>   I understand that the default (False) means that tables are created
>   in any case, even if they exist already.  Wouldn't it be a better
>   default to create them only if they don't exist already?  (Does it
>   raise an exception if already existing tables are re-created or does
>   it simply drop the old ones? -- maybe you could add that to the
>   doc).  My rational for asking for this default is that it seems
>   safer and the option could possibly be called "force" instead of
>   ifNotExists--that seems closer to what I would expect (at least in a
>   Unix environment).
> 
> * dropTable(ifExists=..):
>   is this really necessary?  What happens if it does not exist
>   (nothing or exception)?  Maybe there is something I don't
>   understand, but I would be happy that after calling dropTable, the
>   table is gone (or else, an exception is raised) no matter what the
>   state was before.  (I try to avoid methods with pre-conditions as
>   much as ever possible)

To me these should act something like mkdir and rmdir do in the
filesystem, or like the CREATE and DROP commands do in the database. 
You should *know* that the tables do or do not exist at the time you run
these commands, and if things are not as you expect you should get an
error (actually generated by the database).

In particular for testing or example situations, where you expect for
junk to have been left around, being tolerant is well and good.  But by
default I don't believe they should be tolerant.

> * dropTable(dropJoinTables=...):
>   I am wondering whether it makes sense to keep joinTables around
>   since really they make reference to rows in the table and leaving
>   them around leads to dangling references.  I noted that the SQL you
>   create for relations does not seem to define foreign keys (at least
>   in an example given in the documentation of an earlier version).
>   But if you had the DBMS take care of these, it would probably even
>   complain to leave the joinTable while removing the other table...

Yes, I just left that option in for no particular reason.  There's
probably not a good reason why you'd drop the join but not the table.

Right now the join table is made arbitrarily by one of the SQLObject
classes (whichever one comes alphabetically first, I think), and dropped
along with that same table.  Really I suppose it should be created
whenever the second table is created, and dropped with the first table
is dropped.

  Ian