3
0
Files
corteza/store
Denis Arh 7bde98697a Corteza discovery
- It provides mappings of corteza resources(Namespaces, Modules, Records, Users) along with values to corteza discovery indexer.
- It also save recordLogs for create, update, deletion of resources.
- Extend settings to hold discovery enabled/disabled flag
- Adds URL of compose resources for namespace and record and for module still pending, added todo with notes to code
2022-02-22 17:13:59 +05:30
..
2022-02-22 17:13:59 +05:30
2022-02-22 17:13:59 +05:30
2020-08-26 14:49:33 +02:00
2021-10-05 11:57:36 +05:30
2020-08-26 14:49:33 +02:00
2022-02-10 13:55:54 +01:00
2020-08-26 14:49:33 +02:00
2021-08-16 09:16:07 +02:00
2020-08-26 14:49:33 +02:00
2020-11-26 06:23:24 +01:00
2020-12-13 18:53:19 +01:00
2022-02-22 17:13:59 +05:30
2020-09-15 07:24:28 +02:00
2021-01-04 13:15:53 +01:00
2020-08-26 14:49:33 +02:00
2021-07-08 11:22:11 +02:00
2021-07-08 11:22:11 +02:00
2021-12-20 07:52:48 +01:00
2020-08-26 14:49:33 +02:00
2022-02-22 17:13:59 +05:30
2022-02-22 17:13:59 +05:30
2021-07-08 11:22:11 +02:00
2021-07-08 11:22:11 +02:00
2021-07-08 11:42:18 +02:00
2021-02-12 10:11:57 +01:00
2021-02-12 10:11:57 +01:00
2020-09-09 08:40:50 +02:00

Corteza storage layer

Provides unified storage for Corteza with composable and interchangeable backends. Backends can be any RDBMS, Key-Value, NoSQL, FS, Memory.

FAQ

  • Why are we changing create/update function signature (input struct is no longer returned)? ** Because store functions are no longer manipulating the input.

  • Why naming inconsistency between search/lookup and create/update/...? ** To ensure function names sound more natural

  • Why changing find prefix to search/lookup? ** To be consistent with actions

  • Why do we use custom mapping (and not db:... tag on struct)? Separation of concerns ** consistency with store backends that do not support db tags ** de-cluttering types* namespace

Testing

Running store tests:

make test.store

See Makefile for details

Known issues

SQLite, transactions & locking:: Transactions in SQLite are explicitly disabled due to issues with locking (see sqlite/sqlite.go, line with cfg.TxDisabled # true)

Until this is resolved, SQLite storage backend should not be used in production environment.

We're still keeping and maintaining it to provide the simplest and most performant backend for (service) unit testing to avoid overly complex mocking of storage. This will likely change when we have support for built-in in-memory storage (MEMORY_DSN)