|
From: Andrew B. <an...@ca...> - 2005-07-15 00:54:03
|
On Thu, Jul 14, 2005 at 04:28:19PM -0700, da...@eg... wrote:
[...]
> That's my basic point. In addition, I did try to make
> the argument that I thought selectBy() was an ease-of-use
> API that might lead to more problems than it solves.
> I have, like Andrew, wanted to give selectBy() some
> of the kwargs that select() takes. But since selectBy()
> uses kwargs for its clause specification, this causes
> inherent ambiguity in what the user means. I was
> trying to suggest that perhaps the better approach
> was to allow easier use of select() instead of adding
> functionality to selectBy().
I don't think this is a serious problem with selectBy. It's unlikely that
column names will clash with those keyword arguments. If it is a problem,
we could use a convention like treating "orderBy_" as meaning a column named
"orderBy" -- I think I've seen that used in e.g. Nevow's "stan" API, to
workaround the problem of "class" being a reserved word in Python but also a
common attribute in HTML.
> I hope that's clearer. For the selectOne() functionality
> I would suggest adding the kwarg 'unique' to select().
I don't like this -- magic flags that make a method return a different type
of result smell bad to me. The return type of a method ought to be
consistent.
Another way to do this would be a method of SelectResults, but that feels
like an odd place for it:
foo = Foo.select(query).getOneOrNone()
I share your concerns about "there should be only one way to do it", but in
this case I think practicality beats purity.
-Andrew.
|
