So in case anyone was following this: it appears that built-in objects like Date in JavaScript have some internal magic (read: inconsistencies)* that means you can’t proxy them as you would normally.
Not sure if this is fixable in #JSDB. The “solution” might be to discourage use of Date objects and instead persist timestamps. Which is, quite frankly, a pain in the ass.
I do rather love being able to run tail¹ on my database tables² as I work on building Domain³ with Kitten⁴ ;)
(JSDB keeps tables in an append-only JavaScript log which are read fully into memory when the database is opened. And yes, if you noticed the class names, you can store custom objects.)
Breaking change²: data is now evaluated in virtual machine contexts.
If you were persisting custom objects³ and referencing classes from global scope (globalThis) to have your objects keep their types when read, you must now explicitly register your list of custom classes using the new classes property of the options object when calling JSDB.open().
This is quite a major change internally but since #JSDB has 100% code coverage, I’m pretty certain I didn’t break anything else.
Then again, JSDB had 100% code coverage before this too and the issue this update fixes was around for several years. (Likely because no one, including me, was really persisting custom objects… something I’m now starting to use while building #Domain¹.)
Just goes to stress that 100% code coverage in no way means “bug free.” ;)
Right, I just updated Kitten so it includes JSDB version 3.0.0 and it now has built-in support for database app modules.
A database app module is an app module¹ for your database where you can provide a schema for it using JavaScript class hierarchies and register those classes with the database so your custom objects maintain their types when they are written and read in.