Whenever there is a big performance impact it's better not to make assumptions on what is the most common use case. I hate to hear the "web2py is slow" refrain because it's false if you have a good knowledge of web2py. What concerns me is that doing hidden things that impact on performance scares the newcomer and the casual tester.
------- Suppose I am new to web2py, but not a newbie to programming and python. I have a big database and I want to publish things out of it with a nice framework. I know that accessing the db is critical. I heard web2py is easy to use. I do a simple test. I want to know if there are more than one record of the kind I am looking for: len(db(db.long_table.value=='Am I the only one here?').select( db.long_table.id, limitby(0,2))) I expect it faster than count() on a really big table. Result slow as hell. Consequence is ... ok I will use a better framework and I will post somewhere that web2py is nice, but slow, not for serious projects. ------- Even worse in older releases doing a db.long_table(value='Am I the only one here?') was slow, very slow and those shortcuts in web2py code are used everywhere. To the casual user it was the clear sign that no one did serious testing on a large database. mic 2013/10/8 Niphlod <niph...@gmail.com> > the smartest thing to do would be to avoid orderby when there are less > records than paginate. > However, it's unusual to have a query misbehaving for a couple hundreds > records, and I really don't see the point on using grid with paginate=10000. > Given that pagination is 99% of the time required, we need to orderby on > something.... > What we should orderby to then? The only assured field that has an > implicit index is the id (being a PK). Orderby(ing) a PK should definitely > not require a full scan. > I don't see any particular case other than exceptional misbehaving tables > to turn off the ordering. > > > On Tuesday, October 8, 2013 1:53:50 PM UTC+2, Anthony wrote: >> >> >> db.table(id=3) is for returning the sole matching record, so you don't >>>> have to worry about the database's arbitrary ordering of results. But when >>>> using limitby to return a particular subset of records (e.g., when doing >>>> pagination), don't you need to specify an orderby to guarantee that the >>>> results on each query will remain in the same order? >>>> >>>> Yes you need to do it, and you need to do it in a proper way. That is >>> why i think that forcing orderby when limitby is used is not a good idea. >>> Seems just a hack for the grid, not a generic approach. IMHO it's better >>> to be explicit. >>> Consider that on datasets of size comparable to the window imposed by >>> the limitby, the result is that if one uses limitby then he goes slower >>> than without it, because of the implicit orderby. Maybe he wonders why (and >>> all sorts of bad things about web2py ;- ) >>> >> >> I suppose we could default orderby_on_limitby to False in the general >> case and leave it to the developer to explicitly orderby when using >> limitby, but what do you propose for the grid? >> >> Anthony >> >>> -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > 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. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- 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.
