>
> The whole point of having an ORM, is for you to not have to worry about
> the answer to that question - it's gonna do the optimal thing it can, based
> on the circumstances in which it is called.
Has anyone given you any Kool-Aid to drink recently?
> The question of how these cache-management is working, and so whether or
> not you can trust it, is a long and complex question. Suffice it to say,
> that there has been more than a decade of research into this issue, so it
> is solved.
>
Famous last words.
> What about if I need the cities of countries where main language is
>> not Spanish, and population is above 1 millon?
>>
>
> ORMs allow you to attache filters for that, it really depends on the
> implementation, but let's think of some options, shell we?
>
> db.define_table('Language', Field('Name', 'String'))
> db.define_table('Continent', Field('Name', 'string'))
> db.define_table('Country', Field('Name', 'string'), Field('Continent',
> db.Continent))
> db.define_table('City', Field('Name', 'string'), Field('Country', db.
> Country), Field('Language', db.Language), Field('Population', 'Integer'))
>
> >>> spanish = Language(Name='Spanish')
> >>> french = Language(Name='French')
> >>> france.City.Language = french
>
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?
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).
(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.
> 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()".
>>> 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.
Sure, we can quibble over which is more "beautiful", but I haven't seen
anything to justify building a massive ORM. 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.
That could be also archived hacking "Row", but you should use == in
>>
> python for this kind of comparision (equality)
>>
>
> Not is SQLA :)
>
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 *could *do that too.
>
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).
> An ORM is MUCH MORE intuitive, as my examples had demonstrated
>
>
Maybe I missed an example, but I don't think I saw any that were more
intuitive at all, let alone "MUCH MORE" intuitive.
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 web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
