Re: pyDO 2 alpha

On Fri, Apr 22, 2005 at 02:17:00PM -0600, Jonathan Ellis wrote:

> I'm actually looking at pyDO because I was immensely unsatisfied with 
> SQLObject.  SQLObject wants to own my data, but IMO that's my database's 
> job, not my ORM tool's.  (If I wanted it the other way around I'd just 
> use an OODB in the first place.)  I don't want to have to declare my 
> constraints to SQLObject when my db enforces them; just let the 
> exception pass through to me if something goes wrong and I'll handle it.
> 
> This "I own your data, not the db" attitude is bad enough from a Don't 
> Repeat Yourself standpoint, but it's worse, because SQLObject isn't as 
> smart as the db and can't be without re-implementing it entirely.  What 
> if I have a unique constraint declared in the database and (okay, this 
> is a crazy example, but what if) I have a trigger that deals with a 
> potential duplicate by moving the old row into an archive table and 
> replacing it with the new one?  By throwing an exception at the ORM 
> level, SQLObject breaks things.  I was immensely frustrated because I 
> actually do use the power of my database, so having the ORM second-guess 
> me really rubbed the wrong way.
> 
> (So, uh, are you sure you must feature duplication of db constraints in 
> pyDO2? :)

I think very highly of SQLObject and its author's work generally, so
I'm sorry you were immensely unsatisfied; I wouldn't be, but in the
last version of it I looked at, at least, it did seem to enforce
policy more than I would like, particularly in regard to primary keys,
and to be invested in some features, like issueing CREATE TABLE
statements, that imply a sort of primary schema-management role for
the SQLObject layer that to my mind is inappropriate.  (I am highly
suspicious of "database portability" for applications of any
sophistication.)  I think, from reading Bicking's blog, that in fact
he more or less shares my view that an ORM should not aspire to be an
opaque layer over a database, but instead be a way of facilitating the
creation of an application layer with one, so SQLObject's portability
features may perhaps be best thought of as vestigial or at least
inessential.

The theme of PyDO, which is even clearer in the rewrite, in that it be
a very thin layer indeed.  The only constraints you need declare are
those that are actually necessary for the library to operate.  To be
able to have an "updateable result set", which is basically what both
PyDO and SQLObject are, you need to have some way of dealing with
sequences/auto-increment fields, which are the most common kind of
uniqueness constraint.  Other uniqueness constraints are necessary to
distinguish updateable from non-updateable instances (and PyDO accepts
multiple-column constraints here, unlike SQLObject).

PyDO does not actually enforce the uniqueness constraint; it simply
uses it to know that it can expect to get just one thing under certain
circumstances.  Someone might argue that this is just worthless
bookkeeping, and that, in effect, getUnique() should just be
syntactical sugar for getSome(limit=1).  But you don't need uniqueness
constraints in PyDO2; you only need them when:

  1. you want to use a sequence (which implicitly declares a
     uniqueness constraint).
  2. you want to get instances by calling getUnique().
  3. you want to refresh instances (to do so, you need to get 
     a unique one).
  4. you want to delete instances.
  5. you want to update instances.

If you don't want to declare them for some reason, you can still:

  1. perform selects with getSome().
  2. delete stuff with deleteSome().
  3. update stuff with updateSome().
  4. create instances (but not with the "refetch" option to get
     default values; there is no assurance you'd get the same instance
     back).

And of course you can subclass to change the behavior of new(),
update(), and delete().  But I'm at a loss to see why you would want
to, simply to avoid certain declarations, as long as the library
doesn't tell you how you should structure your tables (and PyDO tried
not to).

> The one thing I did like about SQLObject was the _fromDatabase option. 

Which I assume is the schema introspection part.  It is entirely
possible to add and I have stubbed out methods to do it, but it isn't
implemented yet.  I got a bit stuck on implementing it for sqlite, and
thought I'd need to write a SQL parser to do it, but I recently found
that isn't the case.

> I'm pretty busy with Spyce2 right now, but I might be able to get into 
> pyDO code in a couple weeks.  Is the code now or will it be stable 
> enough for eyes other than yours?

I released the alpha because I thought it could take as well as
benefit from some scrutiny.  I've been working on other things, but
I'm going to start writing an application with it and hopefully that
will have the usual effect of flushing out problems.

Cheers, 

js

-- 
Jacob Smullyan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCaYw5uqamFyFXXLIRAhBTAKClKGaHqGq7Y6tz59AmDOOWMbg+uwCgh8NB
he8ZE3DlVvdvRJkoC+2IqHo=
=3ZKM
-----END PGP SIGNATURE-----