> Sadly, there is NO possible way to archive a pythonic list > comprenhension syntax that query the objects in the server side AFAIK > Some libraries uses dis (python disassembler) and other internal & > dirty python hacks to do something similar, please, see: > > http://www.aminus.net/geniusql/ > > http://www.aminus.org/blogs/index.php/2008/04/22/linq-in-python?blog=2 > > http://www.aminus.net/geniusql/chrome/common/doc/trunk/managing.html > > Note that web2py is much closer to the "pythonic expressions", but > without the early / late binding and other issues described there ;-) > > I didn't know about this, but it's not what I meant. It might be a cool concept, but I'm not sure how viable it would be in production. I haven't read everything yet, I'll read it some other time. In my example, there was no "magic" involved, beyond what I've described:
Just to clarify, again, the following syntax: > [city for city in fance.City.list if \ > city.Language is not spanish and city.Population.isGraterThan(1000000)] > Is not a pie-in-the-sky dream-API - there are implementational details > that are viable for each section. > First, the reason the "is not" would work, is that there would exist an > implementation of 'Identity Mapping" that would take care of having a > singleton for each ORM-object representing each row. > Second, the access to france.City.list is viable, as an attribute-access > is totally customization in python, so we can devise anything we want for > the access to do. > For example, it could return an iterator, if the "City" attribute of the > "france" ORM-object is "valid" (meaning, it is cached and not "invalidated" > by a previous transaction-commit), and do a "query" right-there on the > spot, and "return" an iterator, if the "City" attribute of the "france" > ORM-object is "invalid" at the time of the "list" attribute access. > > it was a simple list-comprehension. I "assumes" the data is there - if it isn't, it goes and fetches it. Here is a quote from one of the comments in your second link, that I really resonate with: I think the distinction between: > > Customer.select > > and > > source.Customers > > is quite important as the developer may be thinking quite differently in > each. In the first, I am thinking that I'm grabbing objects from some store > that is linked with the class Customer via an ORM. In the latter, I may > think the same way, but I personally like to think of it as "I've got this > object that has many customers and now I can play with them". That > collection may be backed in a database, or it may just be a collection. > > None of this is not already accomplished either in Python (generators or > list comprehensions) or via the many community modules that address > object-relational mapping or extend what itertools already gives you. > However, what I can't find in Python is a unified API regardless of what > the underlying mechanism of keeping my data is. To me, it doesn't matter if > I'm calling into a for loop or generating a monster SQL statement. I'd > rather write the same code regardless of which of these is going to happen > under the hood. > As for the performance-issue, I've later said this: Well, that depends a lot on the context in which this is executed. > If you have many queries similar to your example, before/around this line > of code, that may reuse the same objects for other purposes (which is not > uncommon) > It may in fact be slower to do it your way in many circumstances, because > every specialized-query you are making is another round-trip to the > database, which would be orders-of-magnitude slower than doing an > eager-loading up-front, and filtering in python. > Also, you need to keep in mind that this is assuming a long-lasting set of > objects that out-live a single transaction-operation. And this: > > Eager-vs-Lazy loading is configurable - both are supported, and you can > use each in you core, depending on circumstances. > As I said in the previouse message (I updated it since you posted this > one). it depends - the trande-offs are circumstancial - that's why you need > both approaches, and the ability to concigure each object to use one or the > other in different circumstances - and that's what SQLA provides. -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
