Re: pyDO 2 alpha
Jacob Smullyan <[email protected]> Mon, 25 Apr 2005 10:50:58 -0400
| Newsgroups | gmane.comp.web.skunkweb |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Apr 25, 2005 at 08:14:13AM -0600, Jonathan Ellis wrote:
> > 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.
>
> That's what I thought, too, until I talked with him about this.
> He definitely wasn't interested in seeing SQLObject becoming less
> intrusive in this respect. So in this instance at least I felt mislead
> by the blog (I think I know the entry you're referring to). Oh, well.
Well, that's OK; that's why sometimes it is a good thing to have More
Than One Way to do something.
> > Other uniqueness constraints are necessary to
> > distinguish updateable from non-updateable instances (and PyDO accepts
> > multiple-column constraints here, unlike SQLObject).
>
> I don't follow what you mean here. What do you mean by a non-updateable
> instance?
An instance that is read-only, either because you have declared that
it is (at the class level), or because there is no uniqueness
constraint at all (so PyDO doesn't know that a SQL UPDATE statement is
just affecting one row or not) or because the row in question has been
deleted.
In case that isn't clear enough, imagine you have a table with one
text column 'word' and no uniqueness constraint (pretty useless
table!). You have a result set with 2 rows (PyDO objects):
[{'word': 'froggie'},
{'word' : 'froggie'}]
Let's say you that PyDO allowed you to update one of them (which it
doesn't), and you do so. The corresponding rows of both instances
would end up getting affected, which violates the instance==row
metaphor that PyDO, I think, has an interest in enforcing.
Cheers,
js
--
Jacob Smullyan
signature.asc
(application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCbQPSuqamFyFXXLIRAk6oAJwIEIFYyz2vGHEkGAqB/yhz6Hm39ACfQa6t 7KrKIluZeUSZDbcdSrxmIUM= =VbN4 -----END PGP SIGNATURE-----