Hello. Sorry for the late answer. I really had been thinking about it all
these days.
On Sat, Jan 26, 2008 at 02:11:26AM -0800, Juerg Lemke wrote:
> would you consider making
> ..select() refuse to work on foreign keys? Or give the
> right result?
>
> An example (I meant to put this on the wiki, but
> couldn't find out how! If someone could upload it onto
> a page 'Using .select() with foreign keys' that might
> be useful for others.):
>
> class X(SQLObject):
>
> pass
>
> class Y(SQLObject):
>
> key = ForeignKey('X')
> pass
>
> X.createTable()
> Y.createTable()
>
> x1=X()
> x2=X()
> x3=X()
>
> y1=Y(key=x1)
> y2=Y(key=x2)
>
> In this example, all the values returned by .select()
> are wrong:
>
> >>> Y.select(Y.q.key==x1).count()
> 4L
> >>> Y.select(Y.q.key==x3).count()
> 2L
> >>> Y.select(Y.q.key!=x1).count()
> 2L
> >>> Y.select(Y.q.key!=x3).count()
> 4L
>
>
> Using, eg, Y.select(Y.q.keyID == x1.id) produces the
> correct result. Perhaps .select() could either produce
> the correct result or fail with an exception if called
> on a foreign key?
Initially I thought it'd be hard if possible at all. The problem is that
.select(), unlike .selectBy(), doesn't get a dict of column names and
values - it gets an SQLExpression (see
http://sqlobject.org/sqlobject-architecture.html)
and it's hard to replace a reference to x1 by reference to x1.id there.
Then I tried to register a converter for SQLObject instances (see
converters.py) but that didn't work - converters aren't called for
inherited classes. But while working on it I got an idea to add a magic
method to the very SQLObject class that allows rendering an SQLObject in
SQLExpressions by returning its id... well, str(id).
That fixes your problem though I have to think about it some more to
find out if it breaks something. And I need to run tests. After that the
fix could land into SQLObject 0.10 beta 2.
> I would be happy to upload this to the wiki, but
> embarassingly I couldn't find out how to add a page...
There are two wikis and both are dead. For the death of the second one
blame me (I didn't properly configured Trac and allowed spammers to poison
wiki and tickets). To make things worse its admin has stopped working on
it.
Now the process of creating a wiki for SQLObject must be started from
the ground. Wiki needs a hosting, a dedictaed admin, a number of active
users...
Oleg.
--
Oleg Broytmann http://phd.pp.ru/ [EMAIL PROTECTED]
Programmers don't die, they just GOSUB without RETURN.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
