View Issue Details

IDProjectCategoryView StatusLast Update
0005649Talerbank API (C)public2019-09-16 09:24
ReporterMarcello StanisciAssigned ToMarcello Stanisci 
PriorityhighSeveritymajorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product VersionSVN HEAD 
Target Version0.6Fixed in Version0.6 
Summary0005649: Specify default value for 'start' from /history
DescriptionWhen '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 InformationThe 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.
TagsNo tags attached.

Activities

Marcello Stanisci

2019-03-18 19:32

manager   ~0014218

This commit: 59075946de79276104c1, adapts the wirewatch behaviour to switch the 'delta' sign after the very first /history request.

Marcello Stanisci

2019-03-18 19:37

manager   ~0014219

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.

Issue History

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 View Revisions
2019-03-15 18:10 Marcello Stanisci Additional Information Updated View Revisions
2019-03-15 18:11 Marcello Stanisci Additional Information Updated View Revisions
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 => SVN HEAD
2019-09-16 09:24 Christian Grothoff Fixed in Version => 0.6
2019-09-16 09:24 Christian Grothoff Target Version => 0.6