Re: [SQLObject] a simple question and small code changes

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

On Thu, 2003-04-03 at 10:28, Peter Wilkinson wrote:
> I did notice that with SQLite due to the way it locks the db you can't 
> do something like:
> for p in Person.select(...):
> 	p.destroy() # this will throw an error about the db being locked

Hmm... youd want to do:

for p in list(Person.select(...)):
    p.destroy()

I kind of makes sense, because you're implicitly modifying the result
while you're iterating, which generally a bad thing.  Using list() makes
the result concrete.

I assume other databases won't have that problem.  Does it give a good
exception message?  If it does, that should be explanation enough...
though I'll put a little note in the docs.

> I imagine this looping and deleting would work fine on other db's so 
> maybe some note in the docs could help anyone else that hits this.
> 
> Another question...
> 
> How do you normally deal with knowing if a row exists in the database?
> e.g. (looking for person id 12 which doesn't exist in db)
> p = Person(12)
> p.id will return 12
> p.name throws an error (likewise for other columns)
> 
> Would something along the lines of p.exists() make any sense?

Yes, Luke was bringing this up before.  Right now I'm considering
getting rid of the lazy updating from the database -- where it fetches
the row only once you've accessed a needed attribute.  Either it should
fetch on instance creation, or if caching is turned off on every
access.  I think there's no good use case for fetching an object where
you really want to put off fetching the column values.  If you care
enough to create the object, you should care enough to want the column
values.

Once that happens, the exists thing should basically be fixed.  I'll add
a class method, so you can do something like Person.exists(12), but
Person(12) will throw an exception.

  Ian