I making no suppositions, I just wonder why most of the databases want that ordering is explicitly required in a query where LIMIT BY/FETCH is present? This is not an issue to many, but since one expect that DAL maps almost one to one to SQL syntax, than behavior (assumption) would be unexpected an old SQL user.
2013/10/9 Derek <sp1d...@gmail.com> > If you blame your lack of skill on a framework then you probably shouldn't > be using that framework. Limitby is supposed to be use to page though > results, or to have a window through results, with the idea being you get > to scroll your window. I think perhaps we could add a 'top(#)' operator > which would be the most obvious choice. > > > On Tuesday, October 8, 2013 4:45:12 PM UTC-7, Michele Comitini wrote: > >> 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 <http://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 <nip...@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 >>> <http://github.com/web2py/web2py>(Source code) >>> - >>> https://code.google.com/p/**web2py/issues/list<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+un...@**googlegroups.com. >>> >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<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. > -- 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.
