I kept running in to issues using DB2 the way I wanted, persistent data between resets and not having the weird requiment of having to do a db2$set() for each script prior to any db2$get() working. Workarounds I had, a dv2$set() in the roots state_entry, worked sometimes, but was inconsisnt and often still resulted in data lose or script-face mismatches.
I've reworked DB2 a little to add the script name as a prefix on the face data, ie:
config{"t":"t","ubm":"96b708c4-8980-4d0d-c4c8-c761b25740b9"}
instead of:
{"t":"t","ubm":"96b708c4-8980-4d0d-c4c8-c761b25740b9"}
db2$index() will trigger the rebuild on the root. The code is mostly shared with DB2_ADD, but will run over every face, the data before the first { is used as the script name in DB2_CACHE.
Might expand on this later to allow more than 2KB per script, but that is likely an edge case that could be handled with db2$setOther() and defining USE_SHARED to a variable.
Ignore the part about DB2_DO_MIGRATE in the commit message, it was something that got left out by accident and did not work as well as I initially thought. The automatic migration was no better at matching scripts to faces and still resulted in data lose.
Its not the biggest flag day xojb has had. :3
I kept running in to issues using DB2 the way I wanted, persistent data between resets and not having the weird requiment of having to do a db2$set() for each script prior to any db2$get() working. Workarounds I had, a dv2$set() in the roots state_entry, worked sometimes, but was inconsisnt and often still resulted in data lose or script-face mismatches.
I've reworked DB2 a little to add the script name as a prefix on the face data, ie: config{"t":"t","ubm":"96b708c4-8980-4d0d-c4c8-c761b25740b9"} instead of: {"t":"t","ubm":"96b708c4-8980-4d0d-c4c8-c761b25740b9"}
db2$index() will trigger the rebuild on the root. The code is mostly shared with DB2_ADD, but will run over every face, the data before the first { is used as the script name in DB2_CACHE.
Might expand on this later to allow more than 2KB per script, but that is likely an edge case that could be handled with db2$setOther() and defining USE_SHARED to a variable.
Ignore the part about DB2_DO_MIGRATE in the commit message, it was something that got left out by accident and did not work as well as I initially thought. The automatic migration was no better at matching scripts to faces and still resulted in data lose. Its not the biggest flag day xojb has had. :3