add getlatestreceipt function on backend

[yichaoyu]

Yaxing, I need a method to get the latest (date/time) receipts. The number of the receipts obtained could be set as the parameter of this method. The mobile end cannot contain too many receipts, so I need to get some of them, the latest ones and usergetallreceipt function is not good. And, usergetreceiptdetail and usergetreceitpitem functions with receipt id as parameter are not suitable for the mobile end either. because it's very hard to get latest receipt by giving the receipt id.

Thanks.

[yaxing]

The current work flow of this should be: using search function, set certain conditions, get a set of receipts order by time, desc. then you can get the id of the receipt you want. Actually you might not need usergetreceiptdetail or usergetreceiptitem func, since search function returns completed receipt entities, including all information of a certain entity.

I'll add searching functions for designated result set size and time.

[yichaoyu]

great thank you ------Original Message------ From: yaxing To: yichao@masxaro.com Subject: Re: [Masxaro-Prototype] add getlatestreceipt function on backend (#26) Sent: Jul 27, 2011 10:06 AM

The current work flow of this should be: using search function, set certain conditions, get a set of receipts order by time, desc. then you can get the id of the receipt you want. Actually you might not need usergetreceiptdetail or usergetreceiptitem func, since search function returns completed receipt entities, including all information of a certain entity.

I'll add searching functions for designated result set size and time.

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

Sent via BlackBerry by AT&T

[Rafe]

I think the search condition building thing is over complicated You don't expect a api user can figure out you need to pass this kind of parameter for receipt search

{
  "con": {
    "LIMIT": {
      "field": {
        "<=":{
          "field":"receipt_time",
          "value": time_range
        }
      "value": limit
  }
}

rather than this:

{
  range : time_range
  limit : limit
}

[yaxing]

The purpose of this design is to generalize the basic searching function so that it would be easy for backend to generate more complex searching APIs for front-end based on one infrastructure func. Also in this case conditions can be indicated in a general way without indicating specific SQL statements. For example, key-word searching, tag searching or time range searching can be build by simply wrapping basic searching function with different condition data, then the parameters of APIs for front-end and other API users would be like:

(notice: for now all keyword, or tags are linked by 'OR', searching result will return the receipts containing any one of the keywords or tags)

{ keys: { 'coffee', 'McDonald', 'burger' } }

or

{ tags: { 'food', 'gym' } }

Therefore you don't have to specify the condition unless there is no corresponding searching API for front-end.

PS. for the condition data structure, now only '=', '>', '<', '<>', '<=', '>=', 'OR', 'AND', 'LIKE' are identifiable, LIMIT should not appear in condition statement. APIs including LIMIT parameter will be updated later.

[Rafe]

It will be simpler if you can ignore "value" and "field" message, and just put single sentence together

{"OR":[
    "A = B",
    "AND":[
        "C=D",
        "D=E"
    ]
]}

In my opinion, I like the ORM-like design better, for example like

$con = new Condition();
$con->where("A=B")->_or("C=D AND D=E")->limit(10);
$control->search($con);

but you can't pass condition as parameter in this way.

However, use the tool that you feel comfortable with.

[yaxing]

time searching API and result set offset (limit) for receipt search functions has been added, you can pull from backend

[yaxing]

Thank you Jimmy, I'll improve the condition builder later, since I designed the current one in a hurry and indeed it seems over complex. Anyway I think it won't have any influences on front-end or mobile-end development, therefore I might modify this next week or next sprint.