> A complex filter on a small set of items might be faster in Python than >> doing another database hit. And a simple filter might belong in the db if >> it has to go over lots of records. As I said, these are orthogonal >> considerations. >> > > Perhaps, but again, we are talking about a context of a statefull system - > we might already have some data on our object-graph - so it's more > complicated then that... >
No, your statement had nothing to do with any of this. Anyway, sounds like you now agree with me that it depends on the context. > - If we're talking about the first query of a transaction, we need to > think about the context of that whole transaction - will we be using all of > the fields in the subsequent attribute-accesses? How about the of the > records? Do we need all of them for our access-pattern later on? How should > we construct our query so it's optimal for re-use of the results in > subsequent attribute-accesses of that same transaction? Such considerations > do not even exist in a stateless system like web2py's DAL - it doesn't have > the same kind of re-usability of returned data. > I think it would help if you are more precise about what you mean by stateless and stateful (preferably with code examples). I don't see why these considerations would not be applicable to web2py. I also don't know why you say web2py lacks re-usability of returned data. Perhaps you could offer some examples. > Conversely, simple-filtering is way too verbose using the DAL - it's an >>> overkill for that, and makes the code much less readable. >>> >> >> Don't know why you think that. >> > > Because it is. > OK, apparently your assertions no longer require arguments and evidence. Perhaps you could have started and ended this entire thread with a much more simple, "Hey, could you people please build an ORM, because I have determined that *it is* better." Then we would all know the truth and could get to coding. > For simple filtering, well, I'd rather do it in python and get >>> readability, becuase the performance-benefits are negligible. >>> >> >> But I thought you were a fan of achieving negligible performance benefits >> at great cost (see below). >> > > Now you're being cynical... > A bit sarcastic, but a serious point -- in one breath you claim to care deeply about what is probably a negligible performance benefit, and in the next you are willing to tolerate some inefficiency. It appears you are being disagreeable for the sake of being disagreeable rather than trying to progress the discussion. > I meant it as a hypothetical-alternative to an imaginary scenario of me >> doing ALL the filtering in python - for THAT I said "well I * >> might-as-well* use NoSql" >> > OK, got it. > Well, you've sure made a lot of claims about what web2py needs without >> knowing much about what it already has. Those are ids. If they were rows, >> then you would just do france.id and spanish.id. >> > > I was simply avoiding making assumptions in that example, as there was no > context for these variables in it. > I was referring to the fact that you didn't know about the .find() method. You also didn't seem to know much about recursive selects, virtual and method fields, etc. > you may still benefit from an "Identity Mapper" in an ORM, in terms of > memory-efficiency Why do you need an ORM to have an identity mapper? And how much benefit are you expecting here? Do you have an example of where this would create big savings? > even if you stick to your ugly "!="s and "=="s.... Ouch, you better tell Guido to change the "equals" and "not equals" operators in Python. > I wouldn't make my decision of having an "Identity Mapper" only for the > usage of "is" and "is not" - in fact, it is rarely used even in SQLA > What do you mean? Since "!=" and "==" are so obviously ugly, aren't all the SQLA users doing "is" and "is not" everywhere, you know, because they can? > - it was just an example of readability that can be harnesses > "is not" is very readable within English prose, but it is not more readable in code (though it can be fairly readable with proper syntax highlighting). 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.
