Re: [SQLObject] Generic "find" & findOne method

[Carlos R. <car...@gm...>]

I'll reply both messages at once, if you don't mind...

On Tue, 21 Dec 2004 19:54:12 +0300, Oleg Broytmann <ph...@ma...> wrote:
> On Tue, Dec 21, 2004 at 02:43:38PM -0200, Carlos Ribeiro wrote:
> > findOne returns a single record. It raises an exception if no item is
> > found. If more than one item is found, it returns the first one
> 
>   Which one? Just random? Is there "orderBy" in findOne?

Random. The use case for findOne assumes that only one record should
be found, anyway. I just don't want to complicate the code or raise an
exception if there is more than one record in the result set. More on
this later.

> > If this code is useful, I can contribute a patch back to SQLObject. It
> > involves simple modifications on dbconnection.py and main.py.
> 
>   Why dbconnection? Seems like a trivial addition in main.py - just
> process the dictionary to generate appropriate WHERE clause, and call
> self.select().

For what I could see, it's discouraged to write SQL code inside the
SQLObject class (at main.py). Also, the select & get methods already
call stuff that is on dbconnection.py.

> > person.find({'name':'...', 'address':'...'})
> 
>   What is the difference between
> person.find({'name':'...', 'address':'...'})
>   and
> person.select(AND(person.q.name == '...', person.q.address == '...'))
>   ???

Let's assume that you have the result of a web form. You can simply
feed the form data to findOne as an argument. One possible example
(using a slightly different and improved syntax):

person.findOne(**form.getData())

There is a good justification for the entire idea. I'm developing a
web application, and in the process, I'm trying to maintain the tiers
as decoupled as possible. All communication between the interface code
and the application code is done using data-only classes, that support
both attribute-style and dict-style access. These intermediate data
structures can also be serialized using something similar to JSON (a
Javascript notation for data exchange). The advantage of this method
is that I can automatically test the application code without the need
to invoke the interface code, just by feeding some hard-coded data
structures to it.

The use case for findOne follows as a consequence. Web forms return a
bunch of data, that are the keys to locate a unique record in the
database. Instead of calling a table.byField() method (using an
alternate key), it's easier and more dynamic just to pass the fields &
values to a generic findOne method. It also makes a little bit easier
to handle the case of composite unique keys, which aren't support by
SQLObject yet.

** As a curiosity, Delphi had such a method (I think it was called
locate) as part of its database API.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...