View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009030 | Taler | wallet-core | public | 2024-07-30 20:22 | 2024-12-13 18:15 |
| Reporter | Florian Dold | Assigned To | Florian Dold | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | low | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.14 | Fixed in Version | 0.14 | ||
| Summary | 0009030: implement getTransactionsV2 API based on materialized transactions | ||||
| Description | We now have materialized transactions. The new getTransactionsV2 API should make use of them! Based on the requirements of the UI, we can implement the new getTransactionsV2 request. The main reason we want this is that currently the UIs are doing a lot of their own heavy lifting w.r.t. searching/filtering/pagination. | ||||
| Tags | No tags attached. | ||||
| related to | 0006588 | informing | Florian Dold | wallet-core should support range queries for the transactions list |
| Fundamentally tx should be filtered by scopeInfo (1st param). Then I basically need 2 types of tx: unfinished vs. finished (2nd param) 1) State == pending / dialog / finalizing/ aborting / suspended-aborting 2) State == done / aborted / suspended / failed / expired Finally, after heavy use there could be hundreds or thousands of finished tx. Thus we need position and count parameters (e.g. pos: 200, count: 40 returns tx 200..239) For unfinished tx I expect no more than a handful for the average user, but of course someone could send hundreds of p2p pull credit (request money) "invoices". If position and count parameters are not set, they default to 0 (pos) and let's say 40 or 50 (count). ___ For each scope, getBalances should return not only the balance (amountAvailable), pendingIncoming and pendingOutgoing, but also countOfFinishedTx and countOfUnfinishedTx. | |
| Tx should have a second timestamp. The first is from the moment the tx got created. var timestamp: Timestamp But, especially for peer-pull-credit, we need a "finished" timestamp which shows the time the tx finished execution. Thus we should rename the first to "created", even though that would make it a breaking API change. And since pending tx are not yet executed, they don't have the second, so it is optional. When sorting a tx list chronologically, it should by default take the finished timestamp. | |
| first comment: agree completely second comment: can we just add a `last_update_timestamp` and do not break the API? maybe we already have something like this my comments: i think we should have something like function getTransactionsV2(scopeInfo, filter?, pagination?) * The only mandatory field should be ScopeInfo since it doesn't make sense to mix currency IMHO ----------- type pagination { offset: TransactionId limit: number order: "asc" | "desc" criteria: "update" | "amount" | ... } The reason for the names in the attributes is to stay consistent with other APIs https://bugs.gnunet.org/view.php?id=7949 1 names are always use `offset` and `limit` 2 `offset` is always the row id or element id (in this case transactionId) 3 `order` is specified as a parameter, not in the limit parameter as a hyphen We can have only 1 criteria, but this make it easy to add more later without breaking API. ----------- type filter { search: RegexString status: Array<TransactionMajorState>; } we can add more filters later but this should be fine | |
| Well, since the result array of getTransactionsV2 consists of new structs (smaller, only basic info, pretty much the "common" part of the full transactions), we don't break anything if we rename "timestamp" to "created" there. And since we need to add a second timestamp, the generic name "timestamp" is no longer appropriate. "created" and "finished" are good names for the two timestamps - "last_update_timestamp" is ugly and way longer than needed! Do we really need a third timestamp named "updated"? What for? If we use a transactionID for offset (instead of index / UInt32), then "nil" or "" (empty string) should be the start or the end of the list, depending on the order. If order == "asc" then the oldest tx comes first, if order == "desc" or is missing, the the newest tx comes first. Example: To get the most recent 3 transactions, you would specify `offset: nil, limit: 3, order: desc`. To get the very first 5: `offset: nil, limit: 5, order: asc`. | |
| > the result array of getTransactionsV2 consists of new structs I didn't thought we were discussing the result, just the input interface... @fdold? Let's make sure we have the interface define before getting into it, @marc do you have a suggestion? | |
| Suggestion for filterByState: enum TransactionStateFilter: String, Codable { case done case final // done, aborted, expired, ... case nonfinal // pending, dialog, suspended, aborting } done is needed for the sparklines (red and green bars in the section header - only tx which did change the balance). final is needed for the main transaction list (and the Recent Transactions section in Balances). Might include refresh tx in debug mode. nonfinal is needed for the pending transaction list. | |
| commit d7d8dee0f6c07b20ec1f1d481a0505f7c87a4055 (HEAD -> master, origin/master, origin/HEAD) Author: Florian Dold <florian@dold.me> Date: Wed Oct 2 17:04:42 2024 +0200 harness: test for new getTransactionsV2 request commit 761e65b5a1da6fc694f8beb1c5784631a9dd545b Author: Florian Dold <florian@dold.me> Date: Wed Oct 2 16:57:20 2024 +0200 wallet-core: implement getTransactionsV2 | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-07-30 20:22 | Florian Dold | New Issue | |
| 2024-07-30 20:22 | Florian Dold | Status | new => assigned |
| 2024-07-30 20:22 | Florian Dold | Assigned To | => Florian Dold |
| 2024-07-30 20:22 | Florian Dold | Summary | implement getTransactionsV2 API based on materialized transactions => implement getTransactionsV2 API based on materialized transactions [design-required] |
| 2024-07-30 21:45 | MarcS | Note Added: 0022872 | |
| 2024-07-31 05:32 | MarcS | Note Added: 0022875 | |
| 2024-07-31 12:31 | sebasjm | Note Added: 0022881 | |
| 2024-07-31 15:56 | MarcS | Note Added: 0022885 | |
| 2024-07-31 17:31 | sebasjm | Note Added: 0022892 | |
| 2024-08-02 07:10 | MarcS | Relationship added | related to 0006588 |
| 2024-09-27 11:42 | MarcS | Note Added: 0023382 | |
| 2024-10-02 15:06 | Florian Dold | Status | assigned => informing |
| 2024-10-02 15:06 | Florian Dold | Resolution | open => fixed |
| 2024-10-02 15:06 | Florian Dold | Note Added: 0023424 | |
| 2024-10-02 15:37 | Florian Dold | Summary | implement getTransactionsV2 API based on materialized transactions [design-required] => implement getTransactionsV2 API based on materialized transactions |
| 2024-10-07 14:35 | Christian Grothoff | Fixed in Version | => 0.14 |
| 2024-12-13 18:15 | Christian Grothoff | Status | informing => closed |