Re: [web2py] Re: Limit SQLFORM.grid results

[Niphlod]

On Wednesday, October 8, 2014 1:00:56 PM UTC+2, Narūnas Krasauskas wrote:
>
>
> I have never said anything like you quoted, what I said though was: "users 
> who can get to the search page ideally would be able to search/see all the 
> records". Meaning, that users has access to the 1+m records, however when 
> they define search query, if one is not accurate enough, it can potentially 
> return really large datasets, therefore I would like to limit output to the 
> defined number of rows.
>
> Imagine you type in the google search "web2py" and hit enter. My browser 
> yields ~373 000 matches, however I can only browse through the first 10 
> pages, that is equal to ~ 100 matches accessible to me, despite the fact 
> that there are 372 900 other ones. My query was not accurate enough and it 
> is obvious to me, obvious to google, that I will not click 37 290 more 
> times, to browse among other matches, I must redefine my query. Does it 
> make sense?
>
> What you have suggested is simply incorrect.
>
>
seems we're in different worlds (or that any issue raised slightly changes 
the original requirements). 
This will be my last addition to this thread. 
Your last "issue" (4) became evident because users in grid CAN order the 
resultset as they please. google doesn't let you do that: ordering is 
strictly fixed and there's a top limit of 1000 elements for every query 
(~100 pages)
tl;dr
- if users has access to 1M records, and they can see everything, it 
doesn't matter how sloppy they are with searches. If the returned dataset 
for the query is - potentially - 1000 records, grid will by default FETCH 
EXACTLY 20 records (paginate default). If users click on SORT, grid will by 
default FETCH EXACTLY 20 records.
- if your table has 1M records and for a sloppy search (i.e. "web2py") your 
database takes one hour to fetch 20 records, web2py can't do anything about 
it
- if your table has 1M records and for a sloppy search your database takes 
2 seconds to fetch 20 records, but 40 minutes to fetch the exact count, and 
you're not concerned about having the count to be exact, figure your own 
logic and pass it to cache_count (that's probably what google does, a rough 
estimate). That's the main point of this original thread posts.
- if you are concerned by NOT LETTING users reach page 4, pass cache_count 
= 80 (or inspect request.vars.page)
- if you are concerned to show users that you have 1M records but they can 
see only 80 of them, grid is not the right tool (or you can meddle with 
javascript fixing the "total records" display at the top)

summary of the summary: you simply can't trim a dataset to whatever you 
like and provide real ordering and let the user see the same set of records 
WITHOUT trimming the entire dataset beforehand.
translation of the summary on issue 4) with evidence on the statement "from 
the end of full dataset": 
given a dataset like [1,2,3,4,.1000]
and your issue of displaying ALWAYS and IRREGARDLESS of ordering JUST 
[1,2,3,4]
you CAN'T pass [1,2,3,4.1000] to the grid and expect that for every 
ordering only a combination of [1,2,3,4] (in whatever order) will be shown.
If you want to do like google, that basically "sells" a 
[1,2,3,4,.373000] while providing a [1,2,3,4.1000], no matter what, 
AND let users choose an order, it means that "the dataset" is no longer 
373000 records. it's 1000 (you can't order a 373000 dataset, then limit it 
to 1000, and expect that the same 1000 records will be shown). And so you 
can approach it doing:
- use cache_count = 373
- instead of db.table pass db.table.id.contains([1,2,3,41000])

summary of the summary of the summary: the order of operations in a 
database (or a dataset) is filtering ("sloppy search") --> ordering --> 
limiting. There's no way around that, is simple logic.
If you want instead to do emulate a "filtering --> limiting --> ordering" 
behaviour, a database query won't fit the bill, because database follow the 
previously explained logic . and so you need to do it in 2 pass: 
database filtering --> fixed dataset rebuild (implicitely limited) --> 
ordering.

-- 
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/d/optout.

Re: [web2py] Re: Limit SQLFORM.grid results

[Narūnas Krasauskas]

2014 m. spalis 8 d., trečiadienis 10:39:37 UTC+1, Niphlod rašė:
>
>  
>
4) If all goes well and I close my eyes to the fact that user will retrieve 
>> slightly more records than I defined in *cache_count*, there still is a 
>> problem. If user would click on the table headers to change sort order - he 
>> would see *cache_count *number of records from the end of full dataset. 
>> (eg. *cache_count=10;* *paginate=4; returned **dataset=52; in this case 
>> user will be able to see first **12 rows, then reorder and see last 12 
>> rows in the dataset, that is 24 rows in total instead of initially desired 
>> 10...)*
>>
>
> Doesn't change what web2py can do. Even if we cut the number of rows 
> displayed exactly as you wish (i.e. 13), they won't be the same if user 
> changes ordering. If you want a fixed set of records that the user needs to 
> see, you need to pass a query to the grid (i.e. 
> db.table.id.belongs((1,2,3,4,5,6,7))). But this clearly defies what you 
> started the question with, that was "my users can see 1+m records anyway"
>

I have never said anything like you quoted, what I said though was: "users 
who can get to the search page ideally would be able to search/see all the 
records". Meaning, that users has access to the 1+m records, however when 
they define search query, if one is not accurate enough, it can potentially 
return really large datasets, therefore I would like to limit output to the 
defined number of rows.

Imagine you type in the google search "web2py" and hit enter. My browser 
yields ~373 000 matches, however I can only browse through the first 10 
pages, that is equal to ~ 100 matches accessible to me, despite the fact 
that there are 372 900 other ones. My query was not accurate enough and it 
is obvious to me, obvious to google, that I will not click 37 290 more 
times, to browse among other matches, I must redefine my query. Does it 
make sense?

What you have suggested is simply incorrect.

-- 
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/d/optout.

Re: [web2py] Re: Limit SQLFORM.grid results

[Niphlod]

given you can pass whatever you want to cache_count, I'd say you can use 
whatever technique you'd like. Of course "approximation" won't never land 
to "perfectness" ;-P

On Wednesday, October 8, 2014 12:45:28 PM UTC+2, Johann Spies wrote:
>
> This thread triggered a thought regarding very large tables: Would it be 
> practical to use the estimates from the backend's query planner to 
> determine cache_count?  If a whole table is selected then one could use the 
> stats from the backend to estimate the total number of rows, but if you 
> execute a query that limits the number of records, the query planner might 
> be of help.
>
> Regards
> Johann
> -- 
> Because experiencing your loyal love is better than life itself, 
> my lips will praise you.  (Psalm 63:3)
>  

-- 
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/d/optout.

Re: [web2py] Re: Limit SQLFORM.grid results

[Johann Spies]

This thread triggered a thought regarding very large tables: Would it be
practical to use the estimates from the backend's query planner to
determine cache_count?  If a whole table is selected then one could use the
stats from the backend to estimate the total number of rows, but if you
execute a query that limits the number of records, the query planner might
be of help.

Regards
Johann
-- 
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)

-- 
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/d/optout.

Re: [web2py] Re: Limit SQLFORM.grid results

[Niphlod]

On Tuesday, October 7, 2014 4:00:56 PM UTC+2, Narūnas Krasauskas wrote:
>
> Hi,
>
> Thanks for the reply.
>
> I just tested my notorious 38 sec query directly on the MySQL, and it also 
> took nearly 40 sec to complete, so after all it was not web2py's fault :-)
>
> Further I also tested *cache_count* option, and indeed like you said, it 
> does something very similar to what I need, thank you for hint!
> However there are few flaws and very unexpected behaviour:
> 1) Giving *cache_count* and *paginate* same values (eg. *cache_count=20*
>  and *paginate=20*) will yield ALL rows at once, without pagination.
>

strange bug. If reproduces, needs fixing.
 

> 2) If a returned dataset is smaller than a *cache_count* - it will show 
> empty pagination breadcrumbs (eg. *cache_count=10;* *paginate=4; 
> dataset=3 - it will show 3 rows on the first page, but still add pages 2 
> and 3 in the breadcrumbs, even tho they are empty... Clicking on them 
> simply yields '*No records found'*)*
>

I won't expect any less. Without giving the possibility to web2py to count 
records, there's no other way around it
 

> 3) If cache_count is not a multiple of a paginate, user will be presented 
> with cache_count + difference records (eg. *cache_count=10;* *paginate=4; 
> will present 12 rows for the user)*
>

Again, cache_count DOES NOT LIMIT the rows. At most, it limits the 
generate(able) pages. Your initial request was requesting exactly this
 

> 4) If all goes well and I close my eyes to the fact that user will 
> retrieve slightly more records than I defined in *cache_count*, there 
> still is a problem. If user would click on the table headers to change sort 
> order - he would see *cache_count *number of records from the end of full 
> dataset. (eg. *cache_count=10;* *paginate=4; returned **dataset=52; in 
> this case user will be able to see first **12 rows, then reorder and see 
> last 12 rows in the dataset, that is 24 rows in total instead of initially 
> desired 10...)*
>

Doesn't change what web2py can do. Even if we cut the number of rows 
displayed exactly as you wish (i.e. 13), they won't be the same if user 
changes ordering. If you want a fixed set of records that the user needs to 
see, you need to pass a query to the grid (i.e. 
db.table.id.belongs((1,2,3,4,5,6,7))). But this clearly defies what you 
started the question with, that was "my users can see 1+m records anyway"


-- 
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/d/optout.

Re: [web2py] Re: Limit SQLFORM.grid results

[Narūnas Krasauskas]

Hi,

Thanks for the reply.

I just tested my notorious 38 sec query directly on the MySQL, and it also 
took nearly 40 sec to complete, so after all it was not web2py's fault :-)

Further I also tested *cache_count* option, and indeed like you said, it 
does something very similar to what I need, thank you for hint!
However there are few flaws and very unexpected behaviour:
1) Giving *cache_count* and *paginate* same values (eg. *cache_count=20*
 and *paginate=20*) will yield ALL rows at once, without pagination..
2) If a returned dataset is smaller than a *cache_count* - it will show 
empty pagination breadcrumbs (eg. *cache_count=10;* *paginate=4; dataset=3 
- it will show 3 rows on the first page, but still add pages 2 and 3 in the 
breadcrumbs, even tho they are empty... Clicking on them simply yields '*No 
records found'*)*
3) If cache_count is not a multiple of a paginate, user will be presented 
with cache_count + difference records (eg. *cache_count=10;* *paginate=4; 
will present 12 rows for the user)*
4) If all goes well and I close my eyes to the fact that user will retrieve 
slightly more records than I defined in *cache_count*, there still is a 
problem. If user would click on the table headers to change sort order - he 
would see *cache_count *number of records from the end of full dataset. 
(eg. *cache_count=10;* *paginate=4; returned **dataset=52; in this case 
user will be able to see first **12 rows, then reorder and see last 12 rows 
in the dataset, that is 24 rows in total instead of initially desired 
10...)*

After #4 in my list my initial "Wow" eventually turned into "It's a 
shame"...

Any hints how to get around these bugs?

Thanks





2014 m. spalis 7 d., antradienis 11:32:16 UTC+1, Niphlod rašė:
>
> Those are not identical queries (constraints DO change, not only 
> pagination). Again, 
>
> select a from table limit 10 offset 0
>
> and 
>
> select a from table limit 10 offset 10
>
> SHOULD DEFINITIVELY NOT have different execution times.
>
> And again, if you want 10 pages of 50 records, just pass paginate=50, 
> cache_count = 500 and it'll do EXACTLY what you want.
>

-- 
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/d/optout.

Re: [web2py] Re: Limit SQLFORM.grid results

[Niphlod]

Those are not identical queries (constraints DO change, not only 
pagination). Again, 

select a from table limit 10 offset 0

and 

select a from table limit 10 offset 10

SHOULD DEFINITIVELY NOT have different execution times.

And again, if you want 10 pages of 50 records, just pass paginate=50, 
cache_count = 500 and it'll do EXACTLY what you want.

-- 
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/d/optout.

Re: [web2py] Re: Limit SQLFORM.grid results

[Narūnas Krasauskas]

Also I wonder, why would you say something like this:

2014 m. spalis 4 d., šeštadienis 20:08:50 UTC+1, Niphlod rašė:
>
> The thing you posted 
> """
> Same story here. I like *grid*, I like pagination, however I'm missing 
> the feature of limiting the total number of rows in the output.
> In my case *grid* can easily generate over 1+m rows in the output, which 
> when paginating by 50 rows per page, would produce 20k+ pages...
> Who needs that many pages? Who would click 20+k times anyway? 
> """
> doesn't point towards something the grid can fix.
>


In fact, I think this is something that grid not just could, or perhaps 
should be doing, besides other great features - let user decide, how many 
rows (or pages) one wants.

If Massimo is not a dirty liar and epydoc is up to date, pagination logic 
is as follows:

#figure out what page we are one to setup the limitby 2364  if paginate 
and dbset._db._adapter.dbengine 
=='google:datastore':
 2365  cursor = request 
.vars 
.cursor or 
True 2366  limitby = (0, paginate) 2367  try: page = 
int 
(request 
.vars 
.page or 
1)-1 2368  except ValueError: page = 0 2369  elif paginate 
and paginatehttp://web2py.com/examples/static/epydoc/gluon.sqlhtml-pysrc.html#>(request 
.vars 
.page or 
1)-1 2371  except ValueError: page = 0 2372  limitby = 
(paginate*page,paginate*(page+1)) 2373  else: 2374  limitby 
= None  

 
So to put everything in the right order, all it takes is replacing few 
lines:

usr_limitby = None # default value must be set somewhere
try: pg_tail = usr_limitby % paginate
except TypeError: limitby = (paginate*page,paginate*(page+1))
else:
if pg_tail == 0: limitby=(paginate*page,int(usr_limitby/paginate))
else: limitby=(paginate*page,int(usr_limitby/paginate)+1)


Or perhaps slicing *nrows.* I dunno, there might be other better ways to do 
it.


-- 
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/d/optout.

Re: [web2py] Re: Limit SQLFORM.grid results

[Narūnas Krasauskas]

Hi, thanks for the reply.

Yes you are right, users who can get to the search page ideally would be 
able to search/see all the records.
However you are not right by saying that there is no performance impact on 
fetching first 50 and next 50, next 1000, etc.

I did some benchmarking, so please have a look at my results as reported by 
the web2py toolbar:

1) Page first loads --> ~2 sec (Not great, but not that bad too)

SELECT  cdr.calldate, cdr.dstchannel, cdr.clid, cdr.src, cdr.dst, cdr.billsec, 
cdr.disposition, cdr.userfield, cdr.lastapp, cdr.uniqueid FROM cdr WHERE 
cdr.lastapp <> 'BackGround') AND (cdr.lastapp <> 'VoiceMail')) AND 
(cdr.lastapp <> 'VoiceMailMain')) AND (cdr.lastapp <> 'Hangup')) AND 
(cdr.lastapp <> 'Playback')) AND (cdr.lastapp <> 'Wait')) AND (cdr.dst REGEXP 
'[^s]{1}')) AND (cdr.calldate < '2014-10-04 20:31:11')) ORDER BY cdr.calldate 
DESC LIMIT 50 OFFSET 0;

2377.98ms2) Getting next 50 records (or page 2 in the paginator 
breadcrumbs) --> again ~2 sec (Not great, but I can live with it)

SELECT  cdr.calldate, cdr.dstchannel, cdr.clid, cdr.src, cdr.dst, cdr.billsec, 
cdr.disposition, cdr.userfield, cdr.lastapp, cdr.uniqueid FROM cdr WHERE 
cdr.lastapp <> 'BackGround') AND (cdr.lastapp <> 'VoiceMail')) AND 
(cdr.lastapp <> 'VoiceMailMain')) AND (cdr.lastapp <> 'Hangup')) AND 
(cdr.lastapp <> 'Playback')) AND (cdr.lastapp <> 'Wait')) AND (cdr.dst REGEXP 
'[^s]{1}')) AND (cdr.calldate < '2014-10-04 20:55:23')) ORDER BY cdr.calldate 
DESC LIMIT 50 OFFSET 50;

2408.69ms
3) #3 --> 2444.45ms, #4 --> 2498.09ms, #5 --> 2525.10ms. And I stopped 
here, as it seemed that pattern is clear, every next page will load in 
roughly 2-3 sec.

4) But see, what happens, if I jump from here to the page 400 --> *38 sec 
!!! o_O*

SELECT  cdr.calldate, cdr.dstchannel, cdr.clid, cdr.src, cdr.dst, cdr.billsec, 
cdr.disposition, cdr.userfield, cdr.lastapp, cdr.uniqueid FROM cdr WHERE 
cdr.lastapp <> 'BackGround') AND (cdr.lastapp <> 'VoiceMail')) AND 
(cdr.lastapp <> 'VoiceMailMain')) AND (cdr.lastapp <> 'Hangup')) AND 
(cdr.lastapp <> 'Playback')) AND (cdr.lastapp <> 'Wait')) AND (cdr.dst REGEXP 
'[^s]{1}')) AND (cdr.calldate < '2014-10-04 21:01:10')) ORDER BY cdr.calldate 
DESC LIMIT 50 OFFSET 19950;

*38364.08ms*
5) I also tried page 4000, just to see, how many minutes that would take, 
but my Nginx timed out with e504...


I probably would have never discovered this issue, if I accidently did not 
click on the last page uri (>>), which also timed out.

My problem is, that in general search would never yield 1m rows, if users 
would use sane queries. However sometimes they need large datasets, and 
there I take advantage of the grid's export features (csv, tsv, xml), but I 
can't tolerate, that if someone will click on the last page, or try to 
change sort order by clicking on the table headers, it will "shut down" the 
system, as it also, like I mentioned, requires tremendous amount of 
resources.

I have an impression, that despite the fact, that it actually slice data 
sets, it also passes over the wire all intermediate results. In my example 
at stage 4, even though it sliced from 19950 to 2 it also sent over the 
wire all those unwanted 19950 records?.. :/ 

Perhaps that is not the case, but you can see, that from 2 sec at the 
beginning it jumped to the almost 40 sec - which is a significant impact on 
the performance, I reckon.







2014 m. spalis 4 d., šeštadienis 20:08:50 UTC+1, Niphlod rašė:
>
> ok, lets reset us the question a bit. 
> This "original" issue had a logic because the grid makes TWO queries by 
> default. One is to retrieve the data for a particular page (and there's 
> NOTHING we can do about it) , the other is to count the total of the 
> records disregarding the pagination.
> Now, if your backend takes a lot of time to retrieve the page-related data 
> you want to show to the user, that a problem you need to fix in your 
> database (or your model, or whatever else).
> What web2py can fix (and did it already) is to avoid counting the 
> additional roundtrip to calculate the total of records (the count can 
> accomodate all kinds of logics now, fixed value, one of your choice, 
> dynamic, caching it, etc.).
>
> The thing you posted 
> """
> Same story here. I like *grid*, I like pagination, however I'm missing 
> the feature of limiting the total number of rows in the output.
> In my case *grid* can easily generate over 1+m rows in the output, which 
> when paginating by 50 rows per page, would produce 20k+ pages...
> Who needs that many pages? Who would click 20+k times anyway? 
> """
> doesn't point towards something the grid can fix.
>
> If records are in your table, and users can see 1 million records because 
> there are no "permission" issues, why would you limit your presentation to 
> only a slice of it ? There's no difference in performances trying to fetch 
> the first 50 records of a 1 million recordset or the next 50. Also, if you 
> don

Re: [web2py] Re: Limit SQLFORM.grid results

[Niphlod]

ok, lets reset us the question a bit. 
This "original" issue had a logic because the grid makes TWO queries by 
default. One is to retrieve the data for a particular page (and there's 
NOTHING we can do about it) , the other is to count the total of the 
records disregarding the pagination.
Now, if your backend takes a lot of time to retrieve the page-related data 
you want to show to the user, that a problem you need to fix in your 
database (or your model, or whatever else).
What web2py can fix (and did it already) is to avoid counting the 
additional roundtrip to calculate the total of records (the count can 
accomodate all kinds of logics now, fixed value, one of your choice, 
dynamic, caching it, etc.).

The thing you posted 
"""
Same story here. I like *grid*, I like pagination, however I'm missing the 
feature of limiting the total number of rows in the output.
In my case *grid* can easily generate over 1+m rows in the output, which 
when paginating by 50 rows per page, would produce 20k+ pages...
Who needs that many pages? Who would click 20+k times anyway? 
"""
doesn't point towards something the grid can fix.

If records are in your table, and users can see 1 million records because 
there are no "permission" issues, why would you limit your presentation to 
only a slice of it ? There's no difference in performances trying to fetch 
the first 50 records of a 1 million recordset or the next 50. Also, if you 
don't want your users to reach page 10, then do a simple math 
(no_of_records_per_page*max_page_they_reach) and set the corresponding 
value to cache_count.

-- 
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/d/optout.

Re: [web2py] Re: Limit SQLFORM.grid results

[Narūnas Krasauskas]

Hi,

Just to make sure we speak same language, below is code snippet that causes 
me problems described in my previous post. Please note search_widget=*None. 
*I use my custom search form, instead of the grid's default, but that's 
just a different html, which should not mess with the matters..
Also note, that my query is mostly based on the time, so selecting a few 
days worth of records work just fine, however few months, a year, etc - 
slow things down to the maximum...

Finally, I'm not quite sure if understood your statement correctly ("just 
pass to grid a query"). I hope you can find out more from my code below.

Thanks

@auth.requires_login(otherwise=URL 
(r=request 
,f='user',args=['login']))
def index():
  ## Hide / Show fields
  db_2.cdr.clid.readable=True
  db_2.cdr.dcontext.readable=False
  db_2.cdr.channel.readable=False
  db_2.cdr.dstchannel.readable=True
  db_2.cdr.lastapp.readable=False
  db_2.cdr.lastdata.readable=False
  db_2.cdr.duration.readable=False
  db_2.cdr.amaflags.readable=False
  db_2.cdr.accountcode.readable=False
  db_2.cdr.uniqueid.readable=True
  db_2.cdr.userfield.readable=False
  db_2.cdr.disposition.readable=True

  ## Filtering rules
  generic_query = (db_2.cdr.lastapp != 'BackGround')
  generic_query &= (db_2.cdr.lastapp != 'VoiceMail')
  generic_query &= (db_2.cdr.lastapp != 'VoiceMailMain')
  generic_query &= (db_2.cdr.lastapp != 'Hangup')
  generic_query &= (db_2.cdr.lastapp != 'Playback')
  generic_query &= (db_2.cdr.lastapp != 'Wait')

  # Initialise GET values
  request 
.vars.date_from = 
date_from
  <...> More code <...>

  # Update final query with user input
  query = generic_query

  ## When start date
  if date_from:
query &= (db_2.cdr.calldate > date_from)
  if date_from and (not date_to):
  <...> More code <...>

  ## Fields to be displayed
  fields = (
db_2.cdr.calldate,
db_2.cdr.dstchannel,
db_2.cdr.clid,
db_2.cdr.src,
db_2.cdr.dst,
db_2.cdr.billsec,
db_2.cdr.disposition,
db_2.cdr.userfield,
db_2.cdr.lastapp,
   )

  ## Define table headers as tuples/dictionaries
  headers = {
 'cdr.calldate': 'Date / Time',
 'cdr.dstchannel': 'Extension',
 'cdr.clid': 'Campaign / User',
 'cdr.src': 'Source',
 'cdr.dst': 'Destination',
 'cdr.billsec': 'Duration',
 'cdr.disposition': 'Disposition',
}

  ## Exports
  from gluon.sqlhtml import ExporterCSV, ExporterTSV
  exportclasses = {
   'html': False,
   'csv': (ExporterCSV, 'CSV'),
   'csv_with_hidden_cols': False,
   'tsv_with_hidden_cols': False,
   'tsv': (ExporterTSV, 'TSV'),
   'json': False,
  }

  ## Sort by Date / Time DESC
  sort_order=[~db_2.cdr.calldate]

  ## Grid object
  form = SQLFORM .grid(
  query=query,
  fields=fields,
  headers=headers,
  orderby=sort_order,
  create=False,
  deletable=False,
  editable=False,
  details=False,
  maxtextlength=64,
  paginate=50,
  exportclasses=exportclasses,
  search_widget=None,
 )

  return dict(form=form)





2014 m. spalis 3 d., penktadienis 14:00:24 UTC+1, Niphlod rašė:
>
> if your backend needs tons of times to extract 50 records (no matter what 
> the page is) there's a problem. Grid has not. If ou want to show your users 
> a set of records, just pass to grid a query instead of the entire table.
>

-- 
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/d/optout.

Re: [web2py] Re: Limit SQLFORM.grid results

[Niphlod]

if your backend needs tons of times to extract 50 records (no matter what 
the page is) there's a problem. Grid has not. If ou want to show your users 
a set of records, just pass to grid a query instead of the entire table.

On Friday, October 3, 2014 12:50:57 PM UTC+2, Narūnas Krasauskas wrote:
>
> Hi,
>
> Same story here. I like *grid*, I like pagination, however I'm missing 
> the feature of limiting the total number of rows in the output.
> In my case *grid* can easily generate over 1+m rows in the output, which 
> when paginating by 50 rows per page, would produce 20k+ pages...
> Who needs that many pages? Who would click 20+k times anyway? 
>
> For instance jumping from the page 19201 to 19202 would eat tremendous 
> amount of resources and may take 20+ sec to complete on my low resources 
> server...
>
> In my scenario an easy workaround would be to sort by date (orderby 
> parameter in the *grid*, which works well and I'm glad it's there) and 
> then display, lets say 1000 rows in total. That would yield 20 pages when 
> paginating by 50 rows per page - excellent.
>
> So I wonder why don't you let the user to decide, how many rows one needs? 
> Why it's all or nothing? If there is orderby, why then limitby is missing? 
> :/ 
>
>
>
>
>
>
>
> 2013 m. gegužė 6 d., pirmadienis 01:22:03 UTC+1, villas rašė:
>>
>> If you don't need the main features of the grid (eg pagination) then it 
>> is better not to use it.  I mean, it is a trivial task to produce a nice 
>> table without pagination.
>>
>> The other option would be to hide the pagination with jQuery,  which 
>> should also be easy to do.
>>
>>
>> On Friday, May 3, 2013 5:54:08 PM UTC+1, Mandar Vaze wrote:
>>>
>>>
>>>
>>> On Monday, April 23, 2012 7:57:23 PM UTC+5:30, Bruce Wade wrote:

 Yeah see that was my original question how to tell grid to only 
 select/count the first 50,000 records instead of it just generating pages 
 for all the records. 

>>>
>>> I understand that this is an year-old thread - but I too have a 
>>> requirement to show ONLY X records out of total Y records it would 
>>> otherwise show across pages.
>>>
>>> Other thing that might work for me is if there is a way to NOT show the 
>>> pagination at all. This way I can set paginate=X and since user can't 
>>> "access" pagination, it would provide similar result as if SQLFORM.grid 
>>> limited the number of records displayed to the user.
>>>
>>> This is useful when you want to show like "Top 10" (Or in case of Bruce 
>>> Above, Top 200 Ads) of some query.
>>>
>>> -Mandar
>>>
>>>  
>>>
>>

-- 
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/d/optout.

[web2py] Re: Limit SQLFORM.grid results

[Narūnas Krasauskas]

Hi,

Same story here. I like *grid*, I like pagination, however I miss the 
feature of limiting the total number of rows in the output.
In my case *grid* can easily generate over 1+m rows in the output, which 
when paginating by 50 rows per page, would produce 20k+ pages...
Who needs that many pages? Who would click 20+k times anyway? 

For instance jumping from the page 19201 to 19202 would eat tremendous 
amount of resources and may take 20+ sec to complete on my low resources 
server...

In my scenario an easy workaround would be to sort by date (orderby 
parameter in the *grid*, which works well and I'm glad it's there) and then 
display, lets say 1000 rows in total. That would yield 20 pages when 
paginating by 50 rows per page - excellent.

So I wonder why don't you let the user to decide, how many rows one needs? 
Why it's all or nothing? If there is orderby, why then limitby is missing? 
:/ 

-- 
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/d/optout.

Re: [web2py] Re: Limit SQLFORM.grid results

[Narūnas Krasauskas]

Hi,

Same story here. I like *grid*, I like pagination, however I'm missing the 
feature of limiting the total number of rows in the output.
In my case *grid* can easily generate over 1+m rows in the output, which 
when paginating by 50 rows per page, would produce 20k+ pages...
Who needs that many pages? Who would click 20+k times anyway? 

For instance jumping from the page 19201 to 19202 would eat tremendous 
amount of resources and may take 20+ sec to complete on my low resources 
server...

In my scenario an easy workaround would be to sort by date (orderby 
parameter in the *grid*, which works well and I'm glad it's there) and then 
display, lets say 1000 rows in total. That would yield 20 pages when 
paginating by 50 rows per page - excellent.

So I wonder why don't you let the user to decide, how many rows one needs? 
Why it's all or nothing? If there is orderby, why then limitby is missing? 
:/ 







2013 m. gegužė 6 d., pirmadienis 01:22:03 UTC+1, villas rašė:
>
> If you don't need the main features of the grid (eg pagination) then it is 
> better not to use it.  I mean, it is a trivial task to produce a nice table 
> without pagination.
>
> The other option would be to hide the pagination with jQuery,  which 
> should also be easy to do.
>
>
> On Friday, May 3, 2013 5:54:08 PM UTC+1, Mandar Vaze wrote:
>>
>>
>>
>> On Monday, April 23, 2012 7:57:23 PM UTC+5:30, Bruce Wade wrote:
>>>
>>> Yeah see that was my original question how to tell grid to only 
>>> select/count the first 50,000 records instead of it just generating pages 
>>> for all the records. 
>>>
>>
>> I understand that this is an year-old thread - but I too have a 
>> requirement to show ONLY X records out of total Y records it would 
>> otherwise show across pages.
>>
>> Other thing that might work for me is if there is a way to NOT show the 
>> pagination at all. This way I can set paginate=X and since user can't 
>> "access" pagination, it would provide similar result as if SQLFORM.grid 
>> limited the number of records displayed to the user.
>>
>> This is useful when you want to show like "Top 10" (Or in case of Bruce 
>> Above, Top 200 Ads) of some query.
>>
>> -Mandar
>>
>>  
>>
>

-- 
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/d/optout.

Re: [web2py] Re: Limit SQLFORM.grid results

[Niphlod]

boys, don't know if you'll use this as a feature or at least a workaround 
for your requirements, but trunk has for grid a "cache_count" parameter.
 
check this thread 
https://groups.google.com/d/msg/web2py/yr2z1M2tzIg/iMLP0sKKbjIJ for the 
docs.

-- 

--- 
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.

Re: [web2py] Re: Limit SQLFORM.grid results

[Richard Vézina]

Interesting :

http://stackoverflow.com/questions/13855304/slow-count-on-postgresql-9-2

Richard


On Mon, May 6, 2013 at 9:35 AM, Richard Vézina
wrote:

> Read the link of Niphold that were broken and it seems that the slow
> counting is gone in Postgres 9.2
>
> Richard
>
>
> On Mon, May 6, 2013 at 9:34 AM, Richard Vézina <
> ml.richard.vez...@gmail.com> wrote:
>
>> http://wiki.postgresql.org/wiki/Slow_Counting
>>
>>
>> On Mon, Apr 23, 2012 at 6:53 AM, Niphlod  wrote:
>>
>>> unfortunately counting on postgres is a heavy operation, and it's pretty
>>> "famous" for this http://wiki.postgresql.org/wiki/Slow_Counting.
>>> maybe you can try limiting the amount to, let's say, 2 (if it's
>>> possible as per requirements of your app) and see if there are differences.
>>>
>>> In theory
>>>
>>> SELECT COUNT(*) from mytable
>>>
>>> and
>>>
>>> SELECT COUNT(*) from mytable LIMIT 2
>>>
>>> for a 50 records table is faster.
>>>
>>> You could have a "default" grid of the 2 records and then an
>>> "advanced" if users are willing to scroll over the n-thousand-x page.
>>>
>>
>>
>

-- 

--- 
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.

Re: [web2py] Re: Limit SQLFORM.grid results

[Richard Vézina]

Read the link of Niphold that were broken and it seems that the slow
counting is gone in Postgres 9.2

Richard


On Mon, May 6, 2013 at 9:34 AM, Richard Vézina
wrote:

> http://wiki.postgresql.org/wiki/Slow_Counting
>
>
> On Mon, Apr 23, 2012 at 6:53 AM, Niphlod  wrote:
>
>> unfortunately counting on postgres is a heavy operation, and it's pretty
>> "famous" for this http://wiki.postgresql.org/wiki/Slow_Counting.
>> maybe you can try limiting the amount to, let's say, 2 (if it's
>> possible as per requirements of your app) and see if there are differences.
>>
>> In theory
>>
>> SELECT COUNT(*) from mytable
>>
>> and
>>
>> SELECT COUNT(*) from mytable LIMIT 2
>>
>> for a 50 records table is faster.
>>
>> You could have a "default" grid of the 2 records and then an
>> "advanced" if users are willing to scroll over the n-thousand-x page.
>>
>
>

-- 

--- 
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.

Re: [web2py] Re: Limit SQLFORM.grid results

[Richard Vézina]

http://wiki.postgresql.org/wiki/Slow_Counting


On Mon, Apr 23, 2012 at 6:53 AM, Niphlod  wrote:

> unfortunately counting on postgres is a heavy operation, and it's pretty
> "famous" for this http://wiki.postgresql.org/wiki/Slow_Counting.
> maybe you can try limiting the amount to, let's say, 2 (if it's
> possible as per requirements of your app) and see if there are differences.
>
> In theory
>
> SELECT COUNT(*) from mytable
>
> and
>
> SELECT COUNT(*) from mytable LIMIT 2
>
> for a 50 records table is faster.
>
> You could have a "default" grid of the 2 records and then an
> "advanced" if users are willing to scroll over the n-thousand-x page.
>

-- 

--- 
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.

Re: [web2py] Re: Limit SQLFORM.grid results

[Mandar Vaze / मंदार वझे]

Villas,

On Mon, May 6, 2013 at 5:52 AM, villas  wrote:
> If you don't need the main features of the grid (eg pagination) then it is
> better not to use it.  I mean, it is a trivial task to produce a nice table
> without pagination.
>
> The other option would be to hide the pagination with jQuery,  which should
> also be easy to do.

Thanks for the suggestion. I'll try jQuery option first.
I use grid because I get a lot of functionality with minimal code
(that I need to maintain/test)
But yes, I agree - creating an HTML table isn't that difficult either.

-Mandar

-- 

--- 
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.

Re: [web2py] Re: Limit SQLFORM.grid results

[villas]

If you don't need the main features of the grid (eg pagination) then it is 
better not to use it.  I mean, it is a trivial task to produce a nice table 
without pagination.

The other option would be to hide the pagination with jQuery,  which should 
also be easy to do.


On Friday, May 3, 2013 5:54:08 PM UTC+1, Mandar Vaze wrote:
>
>
>
> On Monday, April 23, 2012 7:57:23 PM UTC+5:30, Bruce Wade wrote:
>>
>> Yeah see that was my original question how to tell grid to only 
>> select/count the first 50,000 records instead of it just generating pages 
>> for all the records. 
>>
>
> I understand that this is an year-old thread - but I too have a 
> requirement to show ONLY X records out of total Y records it would 
> otherwise show across pages.
>
> Other thing that might work for me is if there is a way to NOT show the 
> pagination at all. This way I can set paginate=X and since user can't 
> "access" pagination, it would provide similar result as if SQLFORM.grid 
> limited the number of records displayed to the user.
>
> This is useful when you want to show like "Top 10" (Or in case of Bruce 
> Above, Top 200 Ads) of some query.
>
> -Mandar
>
>  
>

-- 

--- 
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.

Re: [web2py] Re: Limit SQLFORM.grid results

[Mandar Vaze]

On Monday, April 23, 2012 7:57:23 PM UTC+5:30, Bruce Wade wrote:
>
> Yeah see that was my original question how to tell grid to only 
> select/count the first 50,000 records instead of it just generating pages 
> for all the records. 
>

I understand that this is an year-old thread - but I too have a requirement 
to show ONLY X records out of total Y records it would otherwise show 
across pages.

Other thing that might work for me is if there is a way to NOT show the 
pagination at all. This way I can set paginate=X and since user can't 
"access" pagination, it would provide similar result as if SQLFORM.grid 
limited the number of records displayed to the user.

This is useful when you want to show like "Top 10" (Or in case of Bruce 
Above, Top 200 Ads) of some query.

-Mandar

 

-- 

--- 
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.

Re: [web2py] Re: Limit SQLFORM.grid results

[Massimo Di Pierro]

Bruce,

can you try {{=response.toolbar()}} You will be able to see each query 
performed by the system and how long it took. Count many be the culprit if 
there is not an index associated to the count query.

On Sunday, 22 April 2012 13:35:28 UTC-5, Martin.Mulone wrote:
>
> Perhaps the slowdown comes, counting such amount of records.
>
> 2012/4/22 Massimo Di Pierro 
>
>> This is the logic in sqlhtml.py SQLFORM.grid
>>
>> if paginate and paginate> 
>> limitby = (paginate*page,paginate*(page+1))
>> rows = 
>> dbset.select(left=left,orderby=orderby,limitby=limitby,*table_fields)
>>
>> as you can see it does not fetch all rows when paginating, unless there 
>> is a bug I am now aware of. If there is it should be fixed but need to see 
>> the code that is causing the bug.
>>
>> Massimo
>>
>>
>> On Sunday, 22 April 2012 11:37:14 UTC-5, Bruce Wade wrote:
>>>
>>> The grid is limiting the amount on the page being displayed. however it 
>>> is still querying all the records then creating the pages so you can page 
>>> between them. The query still queries all of the data instead of using 
>>> limits and or ajax. for 50,000 records it takes almost 3-8 seconds to load 
>>> the page.
>>>
>>> db.dailyadviews.id.readable = db.dailyadviews.ad_id.readable = 
>>> db.dailyadviews.viewer_id.**readable = db.dailyadviews.accepted.**readable 
>>> = False
>>> grid = SQLFORM.grid(db.dailyadviews.**ad_id == ad_id,
>>> create=False, editable=False, deletable=False, details=False, 
>>> args=[ad_id]
>>> )
>>>
>>> On Sun, Apr 22, 2012 at 9:26 AM, Massimo Di Pierro <
>>> massimo.dipie...@gmail.com> wrote:
>>>
 This is what I do not understand. If the query is done by the grid, it 
 should limit the number of records to the number of records displayed.
 If that now happening? Are you calling the query outside of the grid?


 On Sunday, 22 April 2012 11:22:32 UTC-5, Bruce Wade wrote:
>
> Yes it has built in pagination, however some of my grids will return 
> over 500,000+ records which causes query's to be very very very slow. I 
> would rather limit the returned data because the average person is not 
> going to go through all them records or care about them. For example 
> currently there has been around 19 million adviews each of these records 
> contains a rating, however there is no way SQLFORM.grid can handle 
> loading 
> that much data.
>
> For some data I can use a date range however other tables we are not 
> storing a date field so I can not use that process to limit the results.
>
> On Sun, Apr 22, 2012 at 9:13 AM, Massimo Di Pierro <
> massimo.dipie...@gmail.com> wrote:
>
>> grid has built-in pagination. Perhaps I do not understand the 
>> question. Can you show us your code?
>>
>>
>> On Sunday, 22 April 2012 10:40:37 UTC-5, Bruce Wade wrote:
>>>
>>> Hi,
>>>
>>> Is there a way to limit the returned results for the grid? I am 
>>> finding that my site has so much data already that most areas where I 
>>> am 
>>> using grid are failing   current 
>>> transaction is aborted, commands ignored until end of transaction block
>>>
>>> If there is no way to limit the results is there a specific reason 
>>> why this was never included?
>>>
>>> -- 
>>> -- 
>>> Regards,
>>> Bruce Wade
>>> http://ca.linkedin.com/in/**brucelwade
>>> http://www.wadecybertech.com
>>> http://www.fittraineronline.**com- 
>>> Fitness Personal Trainers Online
>>> http://www.warplydesigned.com
>>>
>>>  
>
>
> -- 
> -- 
> Regards,
> Bruce Wade
> http://ca.linkedin.com/in/**bruc**elwade
> http://www.wadecybertech.com
> http://www.fittraineronline.**co**m - 
> Fitness Personal Trainers Online
> http://www.warplydesigned.com
>
>  
>>>
>>>
>>> -- 
>>> -- 
>>> Regards,
>>> Bruce Wade
>>> http://ca.linkedin.com/in/**brucelwade
>>> http://www.wadecybertech.com
>>> http://www.fittraineronline.**com  - 
>>> Fitness Personal Trainers Online
>>> http://www.warplydesigned.com
>>>
>>>  
>
>
> -- 
>  http://www.tecnodoc.com.ar
>
>  

Re: [web2py] Re: Limit SQLFORM.grid results

[Bruce Wade]

Yeah see that was my original question how to tell grid to only
select/count the first 50,000 records instead of it just generating pages
for all the records. I single ad in our site has had over 60,000 views.

I am planing to move the adviewer to mongodb if I can't resolve this issue.

On Mon, Apr 23, 2012 at 4:11 AM, Martín Mulone wrote:

> perhaps we can make some lambda to count, but make sure that is the
> count() thing, run some benchmark.
>
>
> 2012/4/23 Niphlod 
>
>> unfortunately counting on postgres is a heavy operation, and it's pretty
>> "famous" for this http://wiki.postgresql.org/wiki/Slow_Counting.
>> maybe you can try limiting the amount to, let's say, 2 (if it's
>> possible as per requirements of your app) and see if there are differences.
>>
>> In theory
>>
>> SELECT COUNT(*) from mytable
>>
>> and
>>
>> SELECT COUNT(*) from mytable LIMIT 2
>>
>> for a 50 records table is faster.
>>
>> You could have a "default" grid of the 2 records and then an
>> "advanced" if users are willing to scroll over the n-thousand-x page.
>>
>
>
>
> --
>  http://www.tecnodoc.com.ar
>
>


-- 
-- 
Regards,
Bruce Wade
http://ca.linkedin.com/in/brucelwade
http://www.wadecybertech.com
http://www.fittraineronline.com - Fitness Personal Trainers Online
http://www.warplydesigned.com

Re: [web2py] Re: Limit SQLFORM.grid results

[Martín Mulone]

perhaps we can make some lambda to count, but make sure that is the count()
thing, run some benchmark.

2012/4/23 Niphlod 

> unfortunately counting on postgres is a heavy operation, and it's pretty
> "famous" for this http://wiki.postgresql.org/wiki/Slow_Counting.
> maybe you can try limiting the amount to, let's say, 2 (if it's
> possible as per requirements of your app) and see if there are differences.
>
> In theory
>
> SELECT COUNT(*) from mytable
>
> and
>
> SELECT COUNT(*) from mytable LIMIT 2
>
> for a 50 records table is faster.
>
> You could have a "default" grid of the 2 records and then an
> "advanced" if users are willing to scroll over the n-thousand-x page.
>



-- 
 http://www.tecnodoc.com.ar

Re: [web2py] Re: Limit SQLFORM.grid results

[Niphlod]

unfortunately counting on postgres is a heavy operation, and it's pretty 
"famous" for this http://wiki.postgresql.org/wiki/Slow_Counting.
maybe you can try limiting the amount to, let's say, 2 (if it's 
possible as per requirements of your app) and see if there are differences.

In theory

SELECT COUNT(*) from mytable

and 

SELECT COUNT(*) from mytable LIMIT 2

for a 50 records table is faster.

You could have a "default" grid of the 2 records and then an "advanced" 
if users are willing to scroll over the n-thousand-x page.

Re: [web2py] Re: Limit SQLFORM.grid results

[Bruce Wade]

Yeah I will add an index I have another table with the same problem so I
think you might be right on the counting taking the most amount of time. Is
there anyway to index on count?

The other table:
db.cash_journal.distributor_id.readable =
db.cash_journal.transaction_id.readable =
db.cash_journal.operator_id.readable = False
db.cash_journal.transaction_type.represent = lambda
transaction_type,row: UCashChangeType.cash_types()[transaction_type]
db.cash_journal.happen_amount.represent = lambda happen_amount,row:
"$%.2f" % happen_amount
db.cash_journal.ucash_before.represent = lambda ucash_before,row:
"$%.2f" % (ucash_before if ucash_before else 0)
db.cash_journal.ucash_after.represent = lambda ucash_after,row: "$%.2f"
% (ucash_after if ucash_after else 0)

distributor_id = db(db.distributors.account_id ==
auth.user.account_id).select(db.distributors.id)[0]['id']
ucashHistoryGrid = SQLFORM.grid(
(db.cash_journal.distributor_id==distributor_id), orderby=~
db.cash_journal.id,
paginate=10, deletable=False, create=False, editable=False,
details=False, csv=True,
links=[lambda row: A('Transfer Details',
_href=URL("transfer_details", args=[row.transaction_id],
user_signature=True))],
formname='ucash-history',
)

cash_journal current has only 977263 records

On Sun, Apr 22, 2012 at 11:47 AM, simon  wrote:

> Perhaps it is the sorting that is taking the time. Might be worth adding
> an index on ad_id.
>
> On Sunday, 22 April 2012 17:37:14 UTC+1, Bruce Wade wrote:
>>
>> The grid is limiting the amount on the page being displayed. however it
>> is still querying all the records then creating the pages so you can page
>> between them. The query still queries all of the data instead of using
>> limits and or ajax. for 50,000 records it takes almost 3-8 seconds to load
>> the page.
>>
>> db.dailyadviews.id.readable = db.dailyadviews.ad_id.readable =
>> db.dailyadviews.viewer_id.**readable = db.dailyadviews.accepted.**readable
>> = False
>> grid = SQLFORM.grid(db.dailyadviews.**ad_id == ad_id,
>> create=False, editable=False, deletable=False, details=False,
>> args=[ad_id]
>> )
>>
>> On Sun, Apr 22, 2012 at 9:26 AM, Massimo Di Pierro <
>> massimo.dipie...@gmail.com> wrote:
>>
>>> This is what I do not understand. If the query is done by the grid, it
>>> should limit the number of records to the number of records displayed.
>>> If that now happening? Are you calling the query outside of the grid?
>>>
>>>
>>> On Sunday, 22 April 2012 11:22:32 UTC-5, Bruce Wade wrote:

 Yes it has built in pagination, however some of my grids will return
 over 500,000+ records which causes query's to be very very very slow. I
 would rather limit the returned data because the average person is not
 going to go through all them records or care about them. For example
 currently there has been around 19 million adviews each of these records
 contains a rating, however there is no way SQLFORM.grid can handle loading
 that much data.

 For some data I can use a date range however other tables we are not
 storing a date field so I can not use that process to limit the results.

 On Sun, Apr 22, 2012 at 9:13 AM, Massimo Di Pierro <
 massimo.dipie...@gmail.com> wrote:

> grid has built-in pagination. Perhaps I do not understand the
> question. Can you show us your code?
>
>
> On Sunday, 22 April 2012 10:40:37 UTC-5, Bruce Wade wrote:
>>
>> Hi,
>>
>> Is there a way to limit the returned results for the grid? I am
>> finding that my site has so much data already that most areas where I am
>> using grid are failing   current
>> transaction is aborted, commands ignored until end of transaction block
>>
>> If there is no way to limit the results is there a specific reason
>> why this was never included?
>>
>> --
>> --
>> Regards,
>> Bruce Wade
>> http://ca.linkedin.com/in/**brucelwade
>> http://www.wadecybertech.com
>> http://www.fittraineronline.**com- 
>> Fitness Personal Trainers Online
>> http://www.warplydesigned.com
>>
>>


 --
 --
 Regards,
 Bruce Wade
 http://ca.linkedin.com/in/**bruc**elwade
 http://www.wadecybertech.com
 http://www.fittraineronline.**co**m - 
 Fitness Personal Trainers Online
 http://www.warplydesigned.com


>>
>>
>> --
>> --
>> Regards,
>> Bruce Wade
>> http://ca.linkedin.com/in/**brucelwade
>> http://www.wadecybertech.com
>> http://www.fittraineronline.**com  -
>> Fitness Personal Trainers Online
>> http://www.warplydesigned.com
>>
>>
> On Sunday, 22 April 2012 17:37:14 UTC+1, Bruce Wade wrote:
>>
>> The

Re: [web2py] Re: Limit SQLFORM.grid results

[simon]

Perhaps it is the sorting that is taking the time. Might be worth adding an 
index on ad_id. 

On Sunday, 22 April 2012 17:37:14 UTC+1, Bruce Wade wrote:
>
> The grid is limiting the amount on the page being displayed. however it is 
> still querying all the records then creating the pages so you can page 
> between them. The query still queries all of the data instead of using 
> limits and or ajax. for 50,000 records it takes almost 3-8 seconds to load 
> the page.
>
> db.dailyadviews.id.readable = db.dailyadviews.ad_id.readable = 
> db.dailyadviews.viewer_id.readable = db.dailyadviews.accepted.readable = 
> False
> grid = SQLFORM.grid(db.dailyadviews.ad_id == ad_id,
> create=False, editable=False, deletable=False, details=False, 
> args=[ad_id]
> )
>
> On Sun, Apr 22, 2012 at 9:26 AM, Massimo Di Pierro <
> massimo.dipie...@gmail.com> wrote:
>
>> This is what I do not understand. If the query is done by the grid, it 
>> should limit the number of records to the number of records displayed.
>> If that now happening? Are you calling the query outside of the grid?
>>
>>
>> On Sunday, 22 April 2012 11:22:32 UTC-5, Bruce Wade wrote:
>>>
>>> Yes it has built in pagination, however some of my grids will return 
>>> over 500,000+ records which causes query's to be very very very slow. I 
>>> would rather limit the returned data because the average person is not 
>>> going to go through all them records or care about them. For example 
>>> currently there has been around 19 million adviews each of these records 
>>> contains a rating, however there is no way SQLFORM.grid can handle loading 
>>> that much data.
>>>
>>> For some data I can use a date range however other tables we are not 
>>> storing a date field so I can not use that process to limit the results.
>>>
>>> On Sun, Apr 22, 2012 at 9:13 AM, Massimo Di Pierro <
>>> massimo.dipie...@gmail.com> wrote:
>>>
 grid has built-in pagination. Perhaps I do not understand the question. 
 Can you show us your code?


 On Sunday, 22 April 2012 10:40:37 UTC-5, Bruce Wade wrote:
>
> Hi,
>
> Is there a way to limit the returned results for the grid? I am 
> finding that my site has so much data already that most areas where I am 
> using grid are failing   current 
> transaction is aborted, commands ignored until end of transaction block
>
> If there is no way to limit the results is there a specific reason why 
> this was never included?
>
> -- 
> -- 
> Regards,
> Bruce Wade
> http://ca.linkedin.com/in/**bruc**elwade
> http://www.wadecybertech.com
> http://www.fittraineronline.**co**m - 
> Fitness Personal Trainers Online
> http://www.warplydesigned.com
>
>  
>>>
>>>
>>> -- 
>>> -- 
>>> Regards,
>>> Bruce Wade
>>> http://ca.linkedin.com/in/**brucelwade
>>> http://www.wadecybertech.com
>>> http://www.fittraineronline.**com  - 
>>> Fitness Personal Trainers Online
>>> http://www.warplydesigned.com
>>>
>>>  
>
>
> -- 
> -- 
> Regards,
> Bruce Wade
> http://ca.linkedin.com/in/brucelwade
> http://www.wadecybertech.com
> http://www.fittraineronline.com - Fitness Personal Trainers Online
> http://www.warplydesigned.com
>
>  
On Sunday, 22 April 2012 17:37:14 UTC+1, Bruce Wade wrote:
>
> The grid is limiting the amount on the page being displayed. however it is 
> still querying all the records then creating the pages so you can page 
> between them. The query still queries all of the data instead of using 
> limits and or ajax. for 50,000 records it takes almost 3-8 seconds to load 
> the page.
>
> db.dailyadviews.id.readable = db.dailyadviews.ad_id.readable = 
> db.dailyadviews.viewer_id.readable = db.dailyadviews.accepted.readable = 
> False
> grid = SQLFORM.grid(db.dailyadviews.ad_id == ad_id,
> create=False, editable=False, deletable=False, details=False, 
> args=[ad_id]
> )
>
> On Sun, Apr 22, 2012 at 9:26 AM, Massimo Di Pierro <
> massimo.dipie...@gmail.com> wrote:
>
>> This is what I do not understand. If the query is done by the grid, it 
>> should limit the number of records to the number of records displayed.
>> If that now happening? Are you calling the query outside of the grid?
>>
>>
>> On Sunday, 22 April 2012 11:22:32 UTC-5, Bruce Wade wrote:
>>>
>>> Yes it has built in pagination, however some of my grids will return 
>>> over 500,000+ records which causes query's to be very very very slow. I 
>>> would rather limit the returned data because the average person is not 
>>> going to go through all them records or care about them. For example 
>>> currently there has been around 19 million adviews each of these records 
>>> contains a rating, however there is no way SQLFORM.grid can handle loading 
>>> that much data.
>>>
>>> For some data I can use a date range however other tables w

Re: [web2py] Re: Limit SQLFORM.grid results

[Martín Mulone]

Perhaps the slowdown comes, counting such amount of records.

2012/4/22 Massimo Di Pierro 

> This is the logic in sqlhtml.py SQLFORM.grid
>
> if paginate and paginate 
> limitby = (paginate*page,paginate*(page+1))
> rows =
> dbset.select(left=left,orderby=orderby,limitby=limitby,*table_fields)
>
> as you can see it does not fetch all rows when paginating, unless there is
> a bug I am now aware of. If there is it should be fixed but need to see the
> code that is causing the bug.
>
> Massimo
>
>
> On Sunday, 22 April 2012 11:37:14 UTC-5, Bruce Wade wrote:
>>
>> The grid is limiting the amount on the page being displayed. however it
>> is still querying all the records then creating the pages so you can page
>> between them. The query still queries all of the data instead of using
>> limits and or ajax. for 50,000 records it takes almost 3-8 seconds to load
>> the page.
>>
>> db.dailyadviews.id.readable = db.dailyadviews.ad_id.readable =
>> db.dailyadviews.viewer_id.**readable = db.dailyadviews.accepted.**readable
>> = False
>> grid = SQLFORM.grid(db.dailyadviews.**ad_id == ad_id,
>> create=False, editable=False, deletable=False, details=False,
>> args=[ad_id]
>> )
>>
>> On Sun, Apr 22, 2012 at 9:26 AM, Massimo Di Pierro <
>> massimo.dipie...@gmail.com> wrote:
>>
>>> This is what I do not understand. If the query is done by the grid, it
>>> should limit the number of records to the number of records displayed.
>>> If that now happening? Are you calling the query outside of the grid?
>>>
>>>
>>> On Sunday, 22 April 2012 11:22:32 UTC-5, Bruce Wade wrote:

 Yes it has built in pagination, however some of my grids will return
 over 500,000+ records which causes query's to be very very very slow. I
 would rather limit the returned data because the average person is not
 going to go through all them records or care about them. For example
 currently there has been around 19 million adviews each of these records
 contains a rating, however there is no way SQLFORM.grid can handle loading
 that much data.

 For some data I can use a date range however other tables we are not
 storing a date field so I can not use that process to limit the results.

 On Sun, Apr 22, 2012 at 9:13 AM, Massimo Di Pierro <
 massimo.dipie...@gmail.com> wrote:

> grid has built-in pagination. Perhaps I do not understand the
> question. Can you show us your code?
>
>
> On Sunday, 22 April 2012 10:40:37 UTC-5, Bruce Wade wrote:
>>
>> Hi,
>>
>> Is there a way to limit the returned results for the grid? I am
>> finding that my site has so much data already that most areas where I am
>> using grid are failing   current
>> transaction is aborted, commands ignored until end of transaction block
>>
>> If there is no way to limit the results is there a specific reason
>> why this was never included?
>>
>> --
>> --
>> Regards,
>> Bruce Wade
>> http://ca.linkedin.com/in/**brucelwade
>> http://www.wadecybertech.com
>> http://www.fittraineronline.**com- 
>> Fitness Personal Trainers Online
>> http://www.warplydesigned.com
>>
>>


 --
 --
 Regards,
 Bruce Wade
 http://ca.linkedin.com/in/**bruc**elwade
 http://www.wadecybertech.com
 http://www.fittraineronline.**co**m - 
 Fitness Personal Trainers Online
 http://www.warplydesigned.com


>>
>>
>> --
>> --
>> Regards,
>> Bruce Wade
>> http://ca.linkedin.com/in/**brucelwade
>> http://www.wadecybertech.com
>> http://www.fittraineronline.**com  -
>> Fitness Personal Trainers Online
>> http://www.warplydesigned.com
>>
>>


-- 
 http://www.tecnodoc.com.ar

Re: [web2py] Re: Limit SQLFORM.grid results

[Massimo Di Pierro]

This is the logic in sqlhtml.py SQLFORM.grid

if paginate and paginate
> The grid is limiting the amount on the page being displayed. however it is 
> still querying all the records then creating the pages so you can page 
> between them. The query still queries all of the data instead of using 
> limits and or ajax. for 50,000 records it takes almost 3-8 seconds to load 
> the page.
>
> db.dailyadviews.id.readable = db.dailyadviews.ad_id.readable = 
> db.dailyadviews.viewer_id.readable = db.dailyadviews.accepted.readable = 
> False
> grid = SQLFORM.grid(db.dailyadviews.ad_id == ad_id,
> create=False, editable=False, deletable=False, details=False, 
> args=[ad_id]
> )
>
> On Sun, Apr 22, 2012 at 9:26 AM, Massimo Di Pierro <
> massimo.dipie...@gmail.com> wrote:
>
>> This is what I do not understand. If the query is done by the grid, it 
>> should limit the number of records to the number of records displayed.
>> If that now happening? Are you calling the query outside of the grid?
>>
>>
>> On Sunday, 22 April 2012 11:22:32 UTC-5, Bruce Wade wrote:
>>>
>>> Yes it has built in pagination, however some of my grids will return 
>>> over 500,000+ records which causes query's to be very very very slow. I 
>>> would rather limit the returned data because the average person is not 
>>> going to go through all them records or care about them. For example 
>>> currently there has been around 19 million adviews each of these records 
>>> contains a rating, however there is no way SQLFORM.grid can handle loading 
>>> that much data.
>>>
>>> For some data I can use a date range however other tables we are not 
>>> storing a date field so I can not use that process to limit the results.
>>>
>>> On Sun, Apr 22, 2012 at 9:13 AM, Massimo Di Pierro <
>>> massimo.dipie...@gmail.com> wrote:
>>>
 grid has built-in pagination. Perhaps I do not understand the question. 
 Can you show us your code?


 On Sunday, 22 April 2012 10:40:37 UTC-5, Bruce Wade wrote:
>
> Hi,
>
> Is there a way to limit the returned results for the grid? I am 
> finding that my site has so much data already that most areas where I am 
> using grid are failing   current 
> transaction is aborted, commands ignored until end of transaction block
>
> If there is no way to limit the results is there a specific reason why 
> this was never included?
>
> -- 
> -- 
> Regards,
> Bruce Wade
> http://ca.linkedin.com/in/**bruc**elwade
> http://www.wadecybertech.com
> http://www.fittraineronline.**co**m - 
> Fitness Personal Trainers Online
> http://www.warplydesigned.com
>
>  
>>>
>>>
>>> -- 
>>> -- 
>>> Regards,
>>> Bruce Wade
>>> http://ca.linkedin.com/in/**brucelwade
>>> http://www.wadecybertech.com
>>> http://www.fittraineronline.**com  - 
>>> Fitness Personal Trainers Online
>>> http://www.warplydesigned.com
>>>
>>>  
>
>
> -- 
> -- 
> Regards,
> Bruce Wade
> http://ca.linkedin.com/in/brucelwade
> http://www.wadecybertech.com
> http://www.fittraineronline.com - Fitness Personal Trainers Online
> http://www.warplydesigned.com
>
>  

Re: [web2py] Re: Limit SQLFORM.grid results

[Bruce Wade]

The grid is limiting the amount on the page being displayed. however it is
still querying all the records then creating the pages so you can page
between them. The query still queries all of the data instead of using
limits and or ajax. for 50,000 records it takes almost 3-8 seconds to load
the page.

db.dailyadviews.id.readable = db.dailyadviews.ad_id.readable =
db.dailyadviews.viewer_id.readable = db.dailyadviews.accepted.readable =
False
grid = SQLFORM.grid(db.dailyadviews.ad_id == ad_id,
create=False, editable=False, deletable=False, details=False,
args=[ad_id]
)

On Sun, Apr 22, 2012 at 9:26 AM, Massimo Di Pierro <
massimo.dipie...@gmail.com> wrote:

> This is what I do not understand. If the query is done by the grid, it
> should limit the number of records to the number of records displayed.
> If that now happening? Are you calling the query outside of the grid?
>
>
> On Sunday, 22 April 2012 11:22:32 UTC-5, Bruce Wade wrote:
>>
>> Yes it has built in pagination, however some of my grids will return over
>> 500,000+ records which causes query's to be very very very slow. I would
>> rather limit the returned data because the average person is not going to
>> go through all them records or care about them. For example currently there
>> has been around 19 million adviews each of these records contains a rating,
>> however there is no way SQLFORM.grid can handle loading that much data.
>>
>> For some data I can use a date range however other tables we are not
>> storing a date field so I can not use that process to limit the results.
>>
>> On Sun, Apr 22, 2012 at 9:13 AM, Massimo Di Pierro <
>> massimo.dipie...@gmail.com> wrote:
>>
>>> grid has built-in pagination. Perhaps I do not understand the question.
>>> Can you show us your code?
>>>
>>>
>>> On Sunday, 22 April 2012 10:40:37 UTC-5, Bruce Wade wrote:

 Hi,

 Is there a way to limit the returned results for the grid? I am finding
 that my site has so much data already that most areas where I am using grid
 are failing   current transaction is
 aborted, commands ignored until end of transaction block

 If there is no way to limit the results is there a specific reason why
 this was never included?

 --
 --
 Regards,
 Bruce Wade
 http://ca.linkedin.com/in/**bruc**elwade
 http://www.wadecybertech.com
 http://www.fittraineronline.**co**m - 
 Fitness Personal Trainers Online
 http://www.warplydesigned.com


>>
>>
>> --
>> --
>> Regards,
>> Bruce Wade
>> http://ca.linkedin.com/in/**brucelwade
>> http://www.wadecybertech.com
>> http://www.fittraineronline.**com  -
>> Fitness Personal Trainers Online
>> http://www.warplydesigned.com
>>
>>


-- 
-- 
Regards,
Bruce Wade
http://ca.linkedin.com/in/brucelwade
http://www.wadecybertech.com
http://www.fittraineronline.com - Fitness Personal Trainers Online
http://www.warplydesigned.com

Re: [web2py] Re: Limit SQLFORM.grid results

[Massimo Di Pierro]

This is what I do not understand. If the query is done by the grid, it 
should limit the number of records to the number of records displayed.
If that now happening? Are you calling the query outside of the grid?

On Sunday, 22 April 2012 11:22:32 UTC-5, Bruce Wade wrote:
>
> Yes it has built in pagination, however some of my grids will return over 
> 500,000+ records which causes query's to be very very very slow. I would 
> rather limit the returned data because the average person is not going to 
> go through all them records or care about them. For example currently there 
> has been around 19 million adviews each of these records contains a rating, 
> however there is no way SQLFORM.grid can handle loading that much data.
>
> For some data I can use a date range however other tables we are not 
> storing a date field so I can not use that process to limit the results.
>
> On Sun, Apr 22, 2012 at 9:13 AM, Massimo Di Pierro <
> massimo.dipie...@gmail.com> wrote:
>
>> grid has built-in pagination. Perhaps I do not understand the question. 
>> Can you show us your code?
>>
>>
>> On Sunday, 22 April 2012 10:40:37 UTC-5, Bruce Wade wrote:
>>>
>>> Hi,
>>>
>>> Is there a way to limit the returned results for the grid? I am finding 
>>> that my site has so much data already that most areas where I am using grid 
>>> are failing   current transaction is 
>>> aborted, commands ignored until end of transaction block
>>>
>>> If there is no way to limit the results is there a specific reason why 
>>> this was never included?
>>>
>>> -- 
>>> -- 
>>> Regards,
>>> Bruce Wade
>>> http://ca.linkedin.com/in/**brucelwade
>>> http://www.wadecybertech.com
>>> http://www.fittraineronline.**com  - 
>>> Fitness Personal Trainers Online
>>> http://www.warplydesigned.com
>>>
>>>  
>
>
> -- 
> -- 
> Regards,
> Bruce Wade
> http://ca.linkedin.com/in/brucelwade
> http://www.wadecybertech.com
> http://www.fittraineronline.com - Fitness Personal Trainers Online
> http://www.warplydesigned.com
>
>  

Re: [web2py] Re: Limit SQLFORM.grid results

[Bruce Wade]

Yes it has built in pagination, however some of my grids will return over
500,000+ records which causes query's to be very very very slow. I would
rather limit the returned data because the average person is not going to
go through all them records or care about them. For example currently there
has been around 19 million adviews each of these records contains a rating,
however there is no way SQLFORM.grid can handle loading that much data.

For some data I can use a date range however other tables we are not
storing a date field so I can not use that process to limit the results.

On Sun, Apr 22, 2012 at 9:13 AM, Massimo Di Pierro <
massimo.dipie...@gmail.com> wrote:

> grid has built-in pagination. Perhaps I do not understand the question.
> Can you show us your code?
>
>
> On Sunday, 22 April 2012 10:40:37 UTC-5, Bruce Wade wrote:
>>
>> Hi,
>>
>> Is there a way to limit the returned results for the grid? I am finding
>> that my site has so much data already that most areas where I am using grid
>> are failing   current transaction is
>> aborted, commands ignored until end of transaction block
>>
>> If there is no way to limit the results is there a specific reason why
>> this was never included?
>>
>> --
>> --
>> Regards,
>> Bruce Wade
>> http://ca.linkedin.com/in/**brucelwade
>> http://www.wadecybertech.com
>> http://www.fittraineronline.**com  -
>> Fitness Personal Trainers Online
>> http://www.warplydesigned.com
>>
>>


-- 
-- 
Regards,
Bruce Wade
http://ca.linkedin.com/in/brucelwade
http://www.wadecybertech.com
http://www.fittraineronline.com - Fitness Personal Trainers Online
http://www.warplydesigned.com

[web2py] Re: Limit SQLFORM.grid results

[Massimo Di Pierro]

grid has built-in pagination. Perhaps I do not understand the question. Can 
you show us your code?

On Sunday, 22 April 2012 10:40:37 UTC-5, Bruce Wade wrote:
>
> Hi,
>
> Is there a way to limit the returned results for the grid? I am finding 
> that my site has so much data already that most areas where I am using grid 
> are failing   current transaction is 
> aborted, commands ignored until end of transaction block
>
> If there is no way to limit the results is there a specific reason why 
> this was never included?
>
> -- 
> -- 
> Regards,
> Bruce Wade
> http://ca.linkedin.com/in/brucelwade
> http://www.wadecybertech.com
> http://www.fittraineronline.com - Fitness Personal Trainers Online
> http://www.warplydesigned.com
>
>