From orm-devel@mailman.tux4web.de Mon Jun 23 16:20:46 2003 From: orm-devel@mailman.tux4web.de (Kevin Howe) Date: Mon, 23 Jun 2003 11:20:46 -0400 Subject: [orm-devel] Re: [orm-users] orm with mxODBC References: <004701c334e1$9a752400$11483141@KHOWE><16111.26376.914604.293044@lisa.tux4web.de><000301c335c2$cc787600$11483141@KHOWE><16112.48487.192188.967115@lisa.tux4web.de><001501c335e0$64d430c0$11483141@KHOWE><16113.60874.919019.973248@lisa.tux4web.de><000401c3368b$2966c1a0$11483141@KHOWE> <16114.50249.881252.116030@lisa.tux4web.de> Message-ID: <001601c3399b$061e77c0$1a00000a@KHOWE> > I'm not sure, how to do this, yet. Perhaps there are not going to be > JOINs, but rather better support for VIEWs (which in turn may contain > JOINs)... I read about this on the mailing list, views are an interesting idea. However if I could put my vote in, the feature I'd like to see implemented would be this one: http://mailman.tux4web.de/pipermail/orm-users/2003-May/000015.html So that you could do queries like the following, which to me seem very natural: # fetch only canadian addresses addresses = person.addresses(country='CA') A very useful yet simple extension of this would be to allow the passing of an "operator" object in order to specify a condition: import ops # employees older than 25 company.employees(age=ops.GT(25)) # employees of certain ages only company.employees(age=ops.IN(25, 30) Where "ops" would contain a class for each operator type. In the above example we have the "greater than" and "in" operator classes. Each operator class's __repr__ method would return the appropriate sql condition: GT would produce: Age > 25 IN would produce: Age IN (25, 30) Anything more complex than this would be left to runSelect(). - Kevin From orm-devel@mailman.tux4web.de Mon Jun 23 20:21:10 2003 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Mon, 23 Jun 2003 21:21:10 +0200 Subject: [orm-devel] Re: [orm-users] subsets of results / operators (was: orm with mxODBC) In-Reply-To: <001601c3399b$061e77c0$1a00000a@KHOWE> References: <004701c334e1$9a752400$11483141@KHOWE> <16111.26376.914604.293044@lisa.tux4web.de> <000301c335c2$cc787600$11483141@KHOWE> <16112.48487.192188.967115@lisa.tux4web.de> <001501c335e0$64d430c0$11483141@KHOWE> <16113.60874.919019.973248@lisa.tux4web.de> <000401c3368b$2966c1a0$11483141@KHOWE> <16114.50249.881252.116030@lisa.tux4web.de> <001601c3399b$061e77c0$1a00000a@KHOWE> Message-ID: <16119.21286.239189.15227@lisa.tux4web.de> >So that you could do queries like the following, which to me seem very >natural: > ># fetch only canadian addresses >addresses = person.addresses(country='CA') Yes, I'll do something like this. My question: In your idea, are the addresses retrieved from the database stored in the person object? Right now they are, but I'm not actually using this 'feature'. It would make ORM reasonably simpler if that would not be required. But it also means that: for address in person.addresses(): print address.city for address in person.addresses(): print address.zipcode will cause two queries. Is that allright? I can think of a chaching system, too, but this would raise the level of complexity of orm and the level of subtleness of its use. >A very useful yet simple extension of this would be to allow the passing of >an "operator" object in order to specify a condition: Yes, I like this... I'll think about it. Would you be interested in writing it yourself...? Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---`