|
From: Peter W. <pw-...@te...> - 2003-04-02 15:44:38
|
Hi. I've just started having a look at SQLObject and so far very impressed - seems nice and natural. I'm using the download from the website, not cvs, and can't find a way to delete a row from the database, is there something that I'm overlooking or is this not implemented yet? Also I've been using SQLite quite extensively lately and noticed a couple of places in DBConnection.py that can be added to/changed. To find if a table exists (def tableExists) in SQLite use: select tbl_name from sqlite_master where type='table' where tbl_name = 'TABLE' Also createIDColumn should be: return '%s INTEGER PRIMARY KEY' % soClass._idName INTEGER is the only type specified that means anything to SQLite. Hope that helps. Again looking good so far :-) -- peter w. |
|
From: Frank B. <fb...@fo...> - 2003-04-02 16:11:52
|
Hallo, Peter Wilkinson hat gesagt: // Peter Wilkinson wrote: > Also I've been using SQLite quite extensively lately and noticed a > couple of places in DBConnection.py that can be added to/changed. > > To find if a table exists (def tableExists) in SQLite use: > select tbl_name from sqlite_master where type='table' where tbl_name = > 'TABLE' > > Also createIDColumn should be: > return '%s INTEGER PRIMARY KEY' % soClass._idName > INTEGER is the only type specified that means anything to SQLite. Cool. I didn't have time (and won't have the next week) to adapt the new db-creation changes for SQLite. They should in general be very easy, as SQLIte is typeless and just gives back, what you throw at it. BTW: Did you use sqlite/sqlobject in a threaded environment like Webware already? Somehow I couldn't get this to work properly. ciao -- Frank Barknecht _ ______footils.org__ |
|
From: Ian B. <ia...@co...> - 2003-04-02 19:10:26
|
On Wed, 2003-04-02 at 09:43, Peter Wilkinson wrote: > Hi. > I've just started having a look at SQLObject and so far very impressed > - seems nice and natural. > > I'm using the download from the website, not cvs, and can't find a way > to delete a row from the database, is there something that I'm > overlooking or is this not implemented yet? You can call .destroy() on the instance you want to kill. It should probably be a class method, as self-destruction isn't very pythonic... but anyway, it's there. > Also I've been using SQLite quite extensively lately and noticed a > couple of places in DBConnection.py that can be added to/changed. Cool, I've added those to CVS (haven't installed SQLite, so might still have a typo ;) Ian |
|
From: Peter W. <pw-...@te...> - 2003-04-03 16:29:54
|
On Thursday, April 3, 2003, at 05:11 AM, Ian Bicking wrote: > You can call .destroy() on the instance you want to kill. It should > probably be a class method, as self-destruction isn't very pythonic... > but anyway, it's there. > Thanks very much Ian - I should have seen that in source... 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 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? Oh and I'm new-ish to Python so I may well being missing the obvious :-) -- peter w. |
|
From: Luke O. <lu...@me...> - 2003-04-03 17:12:21
|
>
> 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?
This is something that is missing from SQLObject, IMO. There
are two possibilities as I see if for fixed functionality:
p = Person(12) still works, and we add p.exists() as a
function (functionality already exists in the DBConnection,
as it is what makes p.name fail).
or
p = Person(12) throws an exception (KeyError?) (based on
internally calling self.exists()/equivalent).
I prefer option two, as I can't come up with a scenario
where I want an invalid Person object to be instantiated;
it means that everytime I instantiate an object I'll end up
calling .exists() anyways. I suppose the downside is for
.select(), as there is now an SQL check for every
instantiation, when we're pretty confident the objects
exist... but it's price I'm willing to pay, especially with
caching on. Hmm.
Public .exists() functionality should be available too, for
situations where SQLObject-based access is used alongside
other database access methods, since in these cases an
object can become obsolete without SQLObject knowing it
(but these situations are not preferrable, so I would
rather leave it up to the implementor to deal with this
than calling .exists() at every get/update in SQLObject.)
Modified code below (an addition to the end of _init(), and
exists()). This could alternatively be a function in
DBConnection, if we're continuing to move SQL out of
SQLObject.
def _init(self, id, connection=None):
........
# Stop everything if this doesn't exist.
if not self.exists():
raise KeyError, "The object %s by the ID %s does
not exist" % (self.__class__.__name__, self.id)
def exists(self):
q = "SELECT %s FROM %s WHERE %s = %s" % \
(self._idName, self._table, self._idName, self.id)
results = self._connection.queryOne(q)
return bool(results)
Enjoy,
- Luke
|
|
From: Ian B. <ia...@co...> - 2003-04-03 19:41:01
|
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
|
