Thread: [SQLObject] FloatCol, distinct+count and others
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Marcin W. <wo...@un...> - 2004-09-30 07:48:29
|
Hi, I will write about a few things, that make me not 100% happy with SQLObject, in one mail. First about MultipleJoin: as Robert wrote in http://sourceforge.net/mailarchive/forum.php?thread_id=3D5435228&forum_id= =3D30269 person.addresses will generate n+1 queries to DB. About FloatCol, what do you think should be a type of FloatCol? I think double precision in every database (but I'm not sure if other people agree), as I wrote in http://sourceforge.net/mailarchive/forum.php?thread_id=3D5604389&forum_id= =3D30269 About count() in distinct'ed select: now it silently returns not-distinct= ed count. As Jeremy wrote, SQLite doesn't support count(distinct ...), but I think the patch from http://sourceforge.net/mailarchive/forum.php?thread_id=3D5545866&forum_id= =3D30269 would work fine - it works as expected in dbms that support count(distinc= t), and probably raises exception in SQLite, what is better than returning wrong value. And when I found SQLObject, I first downloaded "Mostly Live CVS Tarball". It took me a while to realize, that it is outdated. Now it seems to be older than 0.5.2 tarball. Anyway, I'm quite happy with SQLObject :) Marcin --=20 Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr |
From: Ian B. <ia...@co...> - 2004-09-30 15:43:31
|
Marcin Wojdyr wrote: > Hi, > I will write about a few things, that make me not 100% happy > with SQLObject, in one mail. > > First about MultipleJoin: as Robert wrote in > http://sourceforge.net/mailarchive/forum.php?thread_id=5435228&forum_id=30269 > person.addresses will generate n+1 queries to DB. I don't think that is what happens...? It's certainly not intended to cause that many selects. > About FloatCol, what do you think should be a type of FloatCol? > I think double precision in every database (but I'm not sure if other > people agree), as I wrote in > http://sourceforge.net/mailarchive/forum.php?thread_id=5604389&forum_id=30269 Sure, I guess that's fine. > About count() in distinct'ed select: now it silently returns not-distincted > count. Right now it's supposed to fail with an assertion error. If it's not, I'll have to look into it. Or... > As Jeremy wrote, SQLite doesn't support count(distinct ...), > but I think the patch from > http://sourceforge.net/mailarchive/forum.php?thread_id=5545866&forum_id=30269 > would work fine - it works as expected in dbms that support count(distinct), > and probably raises exception in SQLite, what is better than returning > wrong value. I can just apply that patch. It's probably fine even without cross-database support. > And when I found SQLObject, I first downloaded "Mostly Live CVS Tarball". > It took me a while to realize, that it is outdated. Now it seems to be > older than 0.5.2 tarball. Oops, I have to get rid of that link, thanks. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Robert L. <ro...@le...> - 2004-09-30 18:46:51
|
(Oops, replied directly to Ian - hey, it's 4:45am what else do you expect!) Ian Bicking wrote: > Marcin Wojdyr wrote: > >> Hi, >> I will write about a few things, that make me not 100% happy >> with SQLObject, in one mail. >> >> First about MultipleJoin: as Robert wrote in >> http://sourceforge.net/mailarchive/forum.php?thread_id=5435228&forum_id=30269 >> >> person.addresses will generate n+1 queries to DB. > > > I don't think that is what happens...? It's certainly not intended to > cause that many selects. Unfortunately, it does, at least it does when using Postgres, a fresh install of SQLObject 0.6, Python 2.3.3, W2000 :-( The first select is : SELECT id FROM address WHERE person_id = ### which returns 'n' id's then for every id in the returned list there is : SELECT column(s)... FROM address WHERE id = #### i.e. n+1 queries to DB. Robert |