> Has anyone given you any Kool-Aid to drink recently? >
I have no idea what you mean by that... > > Famous last words. > I have no idea what you mean by that... > > What does france.City.Language = french do? france.City refers to all > cities in France, so does this assign "French" as the language for all > cities? Does SQLA employ that syntax? > Ooops, cought me there... :) Obviously I meant: >>> fance.City.Paris.Language = french The ".Paris" part can be implemented via* __getAttr__* The ".Language = french" part can be implemented via a *Property*. It would obviously treat the primary-key internally, for relationships - but that's a pluming-level thing so it's implicit as a convenience layer. But I like your idea - it could be implemented also! :) > In web2py, this would be: > > french = db.Language.insert(Name='French') > db.Country(france).City.update(Language=french) > > Looks a lot like your example (maybe even a bit more explicit about what's > going on). > There is a hidden fundamental difference - in my approach it is actually making object-references (alongside the database insertion) so that can be used further-on in the code, at the very leas within the same transaction, but even across transactions. Again, this is a domain-model, not just a a database-model. Internally, the values may get invalidated on transaction-sommit, but the object-references would persist within the current runtime. Again, you have to break-away the stateless mind-set and appreciate statefullness. This assumes a very different execution-model than what you are used to in web2py. It is something that would happen within a *module*, not within a *controller-action,* so it is saved within the module-object across transactions/requests/sessions. > > (Note, Mariano's example actually assumed language to be a country-level > field.) > > >>> [city for city in fance.City.list if \ >> city.Language is not spanish and city.Population.isGraterThan(1000000)] >> [<City Name:Paris>] >> > > The problem here is that you are doing all the filtering in Python rather > than in the database. Not a big deal in this example, but with a large > initial set of records, this is inefficient because you will return many > unnecessary records from the database and Python will likely be slower to > do the filtering. > 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. > >> It almost reads like plain English... Beautiful (!) >> > > There are differing opinions on this. Some prefer symbols like != and > > over plain English like "is not" and "isGreaterThan" because it is easier > to scan the line and quickly discern the comparisons being made. In > particular, I would much prefer both typing and reading ">" rather than > ".isGreaterThan()". > You are right - there are different opinions, but the "Zen of Python" is conclusive. :) Also, there are both performance AND memory benefits to using "is not". An object-id check is much faster that an equality check, and having the same object referenced by different names instead of having copies of it that need to be equality-tested, may save tons of memory. But if you insist in using an ugly form, than in my example you may still do that - it would work just as well - while having the same memory-footprint benefits, just not the performance-benefits. :) > > >>> france.City.where( >> Language=not(spanish), Population=moreThan(1000000)) >> >> >>> france.City.FilterBy( >> (City.Languase != spanish) & (City.Population > 1000000)) >> > > In web2py, you can already do: > > db.Country(france).City( > (db.City.Language != spanish) & (db.City.Population > 1000000)).select() > > So far, for every example you have shown, web2py has fairly similar > syntax. > But with radically-different semantics (!!!) > Sure, we can quibble over which is more "beautiful", but I haven't seen > anything to justify building a massive ORM. > It is not just more beautiful - it is also faster for long-transactions, and takes less memory. Also it results in developer code being much more readable and concise and hence much more maintainable. > And the downside of adding an ORM (aside from the time cost of development > and maintenance) is that you would then have to learn yet another > abstraction and syntax. > This doesn't deter people from using SQLA - how do you account for that? > > Well, if you're actually making such a comparison, you generally would > only be interested in "==", not "is" -- it just so happens that "is" would > also be True in SQLA because of the identity mapping. > > web2py is all for stealing great ideas wherever it finds them! :) > Sure, but it could do it at the DAL level, without an ORM. So far, though, > you haven't made a strong case for the utility of such a feature (I don't > doubt that it can be helpful -- the question is how helpful). > So, a smaller memory-footprint, better-performance, readability, conciseness, beauty and ease-of-maintenance for the developers, are all insufficient for your criterion of utility? I wonder what is then... > Maybe I missed an example, but I don't think I saw any that were more > intuitive at all, let alone "MUCH MORE" intuitive. > > Are you seriously suggesting that this: [city for city in fance.City.list if \ city.Language is not spanish and city.Population.isGraterThan(1000000)] Is not much-more intuitive than this?: db.Country(france).City( (db.City.Language != spanish) & (db.City.Population >1000000)).select() If so, than I have no idea what you're talking about... More so, I think you don't even know what you're talking about either... -- --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
