View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003608 | Taler | exchange | public | 2015-01-09 17:59 | 2015-03-22 16:17 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | 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 | urgent | Severity | block | Reproducibility | unable to reproduce |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.0 | Fixed in Version | 0.0 | ||
| Summary | 0003608: need a clean database abstraction (API) and implementation thereof | ||||
| Description | Currently everything is very tied to PG, and the API is a bit of a mess. Having a cleaner abstraction for what DB functions are needed will enable the rest of the mint to be concerned with parsing and serializing replies. Tricky bit: DB logic will need to have a way to return *expressive* error messages, so I suspect we'll want three layers: 1) reply message generation API ("serializing replies"), which is used by 2) DB query API (which takes requests and runs them against the DB) [with plugins so we can have different DB backends] 3) http request API (which parses HTTP requests and passes the queries to the DB query API -- if applicable) Layer (3) kind of exists, layer (1) is all over the place except for some generic low-level builder functions. So maybe a starting point towards this will be to drag all layer (1) functions into a nice response-generation API to be used by all DB implementations. | ||||
| Tags | No tags attached. | ||||
| related to | 0003643 | closed | Christian Grothoff | refresh often loops over many rows in DB |
| DB API currently goes down in 3 layers/levels: (2) taler-mint-httpd_db: DB transaction logic (start, commit/rollback); runs tons of individual statements using (1) (1) mint_db.{c,h}: Postgres-specific statement execution, with help of (0) (0) src/pq/: generic convenience functions to enhance PQ access Layer (2) should still be DB-independent (!), modulo that we currently pass around a "PGconn" object, but that's opaque to (2) and should be easy to replace with an actually opaque handle. This one is big and messy and critical for correctness (so good that we won't have to rewrite it for each backend). Layer (1) is where we'll need to be able to plug in other backends. This one is big and work to port, but trivial code. Layer (0) are convenience functions we'll likely want to port to other backends unless something suitable exists. But this layer is tiny. | |
| /refresh/link is currently the main offender for a clean separation; other /refresh-operations also still require improvements to the mint_db API. | |
| API separation is now complete. However, the implementation of the lowest-level API still needs to be sanity-checked (is likely having serious problems due to functions missing wholesale or not having been fully adopted to variable-size RSA or other API changes). So mint_db.c must still be checked. | |
| Pluginification has now started, several binaries will still need adjustments to their logic to initialize the plugin, and some bits of the plugin logic (vtable initialization) are still missing. But the "big" change is done. | |
| Pluginification complete. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-01-09 17:59 | Christian Grothoff | New Issue | |
| 2015-01-09 17:59 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2015-01-09 17:59 | Christian Grothoff | Status | new => assigned |
| 2015-01-29 00:05 | Christian Grothoff | Note Added: 0008823 | |
| 2015-01-29 15:43 | Christian Grothoff | Target Version | => 0.0 |
| 2015-01-29 19:53 | Christian Grothoff | Note Added: 0008824 | |
| 2015-01-29 20:54 | Christian Grothoff | Summary | need a clean database abstraction (API) => need a clean database abstraction (API) and implementation thereof |
| 2015-01-29 21:00 | Christian Grothoff | Severity | feature => block |
| 2015-01-31 19:57 | Christian Grothoff | Note Added: 0008830 | |
| 2015-01-31 20:06 | Christian Grothoff | Relationship added | related to 0003643 |
| 2015-03-20 23:04 | Christian Grothoff | Note Added: 0009028 | |
| 2015-03-22 13:27 | Christian Grothoff | Note Added: 0009033 | |
| 2015-03-22 13:27 | Christian Grothoff | Status | assigned => informing |
| 2015-03-22 13:27 | Christian Grothoff | Fixed in Version | => 0.0 |
| 2015-03-22 13:27 | Christian Grothoff | Resolution | open => fixed |
| 2015-03-22 16:17 | Christian Grothoff | Status | informing => closed |
| 2016-02-18 14:43 | Christian Grothoff | Category | mint => exchange |