> Has anyone given you any Kool-Aid to drink recently? >> > > I have no idea what you mean by that... >
http://en.wikipedia.org/wiki/Drinking_the_Kool-Aid > >> Famous last words. >> > > I have no idea what you mean by that either... > http://idioms.yourdictionary.com/famous-last-words > 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). >> > > It is not more explicit - it has the same level of explicitness of what's > going on - just less pluming-level explicitness. > More explicit because it makes it clear we are doing an update. > But the important distinction is that 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, > You can save the object and refer to it later in the code in web2py as well. > Again, you have to break-away the stateless mind-set and appreciate > statefullness. > I understand the distinction. You simply haven't yet demonstrated a compelling use case for the latter. > 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. > No, in web applications, SQLA sessions last only as long as a single web request -- basically the same as in web2py. > >>> [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. > Yes, and in that case, you can do something exactly like your code above in web2py (i.e., filtering in Python) -- so what? > Also, you need to keep in mind that this is assuming a long-lasting set of > objects that out-live a single transaction-operation. > Not typically. In most cases, you will probably have one transaction per request in both SQLA and web2py. Furthermore, even if you have multiple transactions within a request, SQLA will expire the state of any instances whenever a transaction is committed. > Also, bare in mind that I am not suggesting to "replace" the DAL, only to > "augment" it with a statefull layer on-top. > Why not augment it with statefulness at the DAL level? Why do you need a layer on top? > The benefits/trade-offs are not absolute/constant - they > vary circumstantially. > Yes, it would help to understand the circumstances in which your preferred features offer substantial benefits. > 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. :) > Where in the "Zen of Python" does it say that English words are more beautiful than boolean operators when expressing boolean logic? > 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. > If you're talking about building queries, your point is moot -- the operations happen in the database, not Python. As for comparisons in Python, in web2py, you wouldn't be testing equality of a whole object/record -- typically it would be a scalar (e.g., the integer ID). And you wouldn't have multiple copies of records in memory either. >>> 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 (!!!) > So what? > 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. > How so? Do you have benchmarks? > Also it results in developer code being much more readable and concise > and hence much more maintainable. > You haven't shown any examples that are more readable or concise, and certainly not 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? > Not entirely sure, as I have not done a sociological study of SQLA users. Perhaps many folks are using primarily just Core or primarily just the ORM and don't worry much about the layer they don't use. It could also be that there are some features they need in the ORM that aren't available or as easy in the Core. That doesn't mean such features have to be implemented via an ORM, though. > 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? > You haven't made any case that there would be a smaller memory footprint or performance let alone quantify these hypothetical improvements. I have seen no improvements in readability, conciseness, or ease of maintenance either -- at least nothing that would remotely justify a massive development and maintenance effort for the framework and the cognitive overhead of learning another abstraction for its users. Anyway, if you just want a little syntactic sugar, that could be built into the DAL without requiring an entire new layer on top of it (and you could probably create the sugar yourself quite easily so you could make it exactly to your taste). Check out http://gluonframework.wordpress.com/2010/07/30/web2py-and-metaclasses/. > 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() > Those two lines are doing different things. You can also do the first one in web2py: [city for city in db.Country(france).select() if \ city.Language != spanish and city.Population > 1000000] What more, I believe you don't even know what you're talking about either... > Please correct me on anything you believe I have said that is mistaken. Regarding knowing what you're talking about, please see above. Anthony -- --- 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.
