pagination

[yaxing]

Hi,

I think we have some issues about pagination here.

What I'm thinking is pagination should be done in front-end and mobile-end, that's why you might want to retrieve all receipts (or most of them, like latest 100) at one time. In this way you won't need to query the database every time user changes a page. And if necessary, you can get new receipts from database using LIMIT parameters that are provided in searching functions. But you need to calculate the LIMIT data based on your self-defined page volume and current page count.

what do you think?

[yichaoyu]

On the mobile end, all info listed in the page will be the basicinfo: store name and date. So all that the app need to store are the basicinfo of all receipts. Every time when a user want to see the detail of a receipt, the app will retrieve it from database if it is not the latest 7 receipts. One thing I'm not sure is whether the tag should be listed in every entry of the pages. Tag is not in the basicinfo of a receipt. ------Original Message------ From: yaxing To: yichao@masxaro.com Subject: [Masxaro-Prototype] pagination (#28) Sent: Jul 28, 2011 9:40 AM

Hi,

I think we have some issues about pagination here.

What I'm thinking is pagination should be done in front-end and mobile-end, that's why you might want to retrieve all receipts (or most of them, like latest 100) at one time. In this way you won't need to query the database every time user changes a page. And if necessary, you can get new receipts from database using LIMIT parameters that are provided in searching functions. But you need to calculate the LIMIT data based on your self-defined page volume and current page count.

what do you think?

Reply to this email directly or view it on GitHub: https://github.com/gpryzby-wtt/Masxaro-Prototype/issues/28

Sent via BlackBerry by AT&T

[Rafe]

It depends on how much receipt user have. I think a request can carry 30~ receipts, client side will cache it and do pagination but, If user want more, than send another request for more.

however, make limit available in get_all_receipt api will be fine.

btw, the second parameter of limit should be the number of records.

[LIMIT {[offset,] _rowcount | _rowcount OFFSET offset}]

http://bjstation.pixnet.net/blog/post/30083625 like limit 5,3 returns 3 records from 5th. So you might want to change the parameter name.

2011/7/28 yaxing < reply@reply.github.com>

Hi,

I think we have some issues about pagination here.

What I'm thinking is pagination should be done in front-end and mobile-end, that's why you might want to retrieve all receipts (or most of them, like latest 100) at one time. In this way you won't need to query the database every time user changes a page. And if necessary, you can get new receipts from database using LIMIT parameters that are provided in searching functions. But you need to calculate the LIMIT data based on your self-defined page volume and current page count.

what do you think?

Reply to this email directly or view it on GitHub: https://github.com/gpryzby-wtt/Masxaro-Prototype/issues/28

[yaxing]

Yes that's what I'm thinking, you can request more receipts from database if necessary. About the limit, yes you're right, I'll change it, thank you.

[bshimkaveg]

Hi Yaxing. I understand there is a thread going on git for this. Let me follow up when I get access. B

Sent from my iPhone

On Jul 28, 2011, at 9:40 AM, yaxingreply@reply.github.com wrote:

Hi,

I think we have some issues about pagination here.

What I'm thinking is pagination should be done in front-end and mobile-end, that's why you might want to retrieve all receipts (or most of them, like latest 100) at one time. In this way you won't need to query the database every time user changes a page. And if necessary, you can get new receipts from database using LIMIT parameters that are provided in searching functions. But you need to calculate the LIMIT data based on your self-defined page volume and current page count.

what do you think?

Reply to this email directly or view it on GitHub: https://github.com/gpryzby-wtt/Masxaro-Prototype/issues/28

[bshimkaveg]

Jimmy / Yaxing, lets go with your plan. If the string search is constrained by date, (Last 7 Days / Last 14 Days / Last Month / Last Year) I think that the returns normally will be not exceed the 30 we might expect...especially for the shorter windows. I think we should also have a custom range option where beginning and ending date windows can be defined this will also reduce the number of returns.

[yaxing]

Yes Brian, and backend APIs do support customized range option now (date range or result set size)