View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005649 | Taler | bank API (C) | public | 2019-03-15 17:35 | 2019-12-20 19:11 |
| Reporter | Marcello Stanisci | Assigned To | Marcello Stanisci | ||
| Priority | high | Severity | major | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.6 | Fixed in Version | 0.6 | ||
| Summary | 0005649: Specify default value for 'start' from /history | ||||
| Description | When 'start' is not given, the current API specs do not mention any difference in the logic when 'delta' is given positive or negative, they only say "delta youngest results will be returned". It is also worth noting, that the current implementation does NOT ignore delta's sign, and makes 'start' default to UINT64_MAX. We have two choices to make the situation clearer: 1) we _ignore_ delta's sign, and specify that *abs(delta)* youngest results are returned. 2) we do not ignore delta's sign, but rather make clear in the docs what the default for 'start' is. Option 2) seems better, as it avoids exceptional cases in the interpretation of 'delta'. On the other hand, this would impact (a little) the wirewatch, as it currently issues *all* the requests with a positive 'delta': #1st request /history?auth=basic&delta=1024&direction=both #2nd to infinite-th request /history?auth=basic&delta=1024&direction=both&start=<latest_row> So with option 2) put in place, the two patterns above would become: #1st request, note the negative sign of 'delta'. /history?auth=basic&delta=-1024&direction=credit #2nd to infinite-th request (no change here). /history?auth=basic&delta=1024&direction=credit&start=<latest_row> As for the default value of 'start', UINT64_MAX seems a better choice than 0 or -1 for the following reasons: since the result having row_id == 'start' is excluded from the results, by picking zero as the default we would surely exclude row_id == 0 for some databases, whereas picking -1 can easily confuse the reader. Clearly, also row_id == UINT64_MAX can be excluded from the result, but this is very unlikely since databases should never reach the point where all the rows got occupied. | ||||
| Additional Information | The current situation puts in danger the wirewatch, since by using a _positive_ delta and omitting the 'start' value, it asks for row_ids bigger the UINT64_MAX! The reason why it _seems_ to work right now is that the exchanges' databases - both from Tripwire and on devs' machines - usually have old entries about previous wire transfers, therefore the wirewatch _tends_ to put a 'start' parameter in the /history requests. | ||||
| Tags | No tags attached. | ||||
|
|
This commit: 59075946de79276104c1, adapts the wirewatch behaviour to switch the 'delta' sign after the very first /history request. |
|
|
API documentation was _already_ matching option 2) in the description; sorry, but https://docs.taler.net isn't updating its content due to 0005490! I'm closing, as all got addressed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-03-15 17:35 | Marcello Stanisci | New Issue | |
| 2019-03-15 17:35 | Marcello Stanisci | Status | new => assigned |
| 2019-03-15 17:35 | Marcello Stanisci | Assigned To | => Christian Grothoff |
| 2019-03-15 17:36 | Marcello Stanisci | Assigned To | Christian Grothoff => Marcello Stanisci |
| 2019-03-15 18:10 | Marcello Stanisci | Description Updated | |
| 2019-03-15 18:10 | Marcello Stanisci | Additional Information Updated | |
| 2019-03-15 18:11 | Marcello Stanisci | Additional Information Updated | |
| 2019-03-18 19:32 | Marcello Stanisci | Note Added: 0014218 | |
| 2019-03-18 19:37 | Marcello Stanisci | Note Added: 0014219 | |
| 2019-03-18 19:38 | Marcello Stanisci | Status | assigned => resolved |
| 2019-03-18 19:38 | Marcello Stanisci | Resolution | open => fixed |
| 2019-09-16 09:24 | Christian Grothoff | Product Version | => git (master) |
| 2019-09-16 09:24 | Christian Grothoff | Fixed in Version | => 0.6 |
| 2019-09-16 09:24 | Christian Grothoff | Target Version | => 0.6 |
| 2019-12-20 19:11 | Christian Grothoff | Status | resolved => closed |
