Draft: TruffleDB LevelDB #4680
Draft: TruffleDB LevelDB #4680
Conversation
tenthirtyone
force-pushed
the
truffledb-leveldb
branch
from
f995434 to
445a658
Compare
… object. add bytecode integration test
packages/db-leveldb/README.md
Outdated
|
|
||
| #### `keyField` - TODO | ||
|
|
||
| Currently set to 'id' for all models. Used to denote a property on the Model that serves as the key used by the database. |
There was a problem hiding this comment.
🎨 Cool to let people change this value. Is there a common reason people do this? Maybe if a key foreign key serves the purpose and you don't need an additional id?
There was a problem hiding this comment.
Yeah, awesome question.
There was an ask that we support Content Addressable Storage IDs. It makes a lot of sense for anything that is deployed. I wasn't sure if an internal 'id' field used by the db and an additional CAS id for the user would be helpful - or if the CAS id could do both roles.
For anything under active development with changing content I think db id + CAS id will help when cycling historical versions as the CAS id would change based on content (especially when multiple devs work off the same project data). And it would make it easier to identify which historical versions made it on chain.
Your point makes a lot of sense and giving the ability to change the key field may introduce more complexity than is necessary. Really, with the way sublevel namespaces the db it would be possible to use something like ${projectName}-CASID as a sort of composite/foreign key solution. Definitely interesting and worth trying or pursuing.
The shorter answer was I just didn't know the correct solution at the time and sided with flexibility until getting some feedback.
…ptional constructor config
<3 |
unit test for multi process leveldb workflow compile with multi process build model instance from historic data add historic to workflow compile
…it tests, fixes ci
Description
A WIP for all things related to truffledb. This draft provides a look at a leveldb implementation that provides the ability to define flexible classes for each model.
The lines changed is deceptive, in all the work is ~350 lines of code supported by 700 of unit tests, readme and a yarn.lock change for the new packages.
I suggest browsing the README for a look at how models are defined, their API and how to create model instances for db records. Then, check the
src/storage/Model.jsfile for the base class that holds the majority of the logic.To Test
$ yarn test