ducharmemp / mobstr Goto Github PK

Due to insights while creating the createIndex function, all of our meta attributes on our classes could be refactored into the store itself. This would allow a leaner class implementation and cause the user classes to go untouched.

Due to the merge of #3, we now have a story in place for indexed values that are complex in shape. Utilizing this same strategy, we can hash lists of index properties and multi-column primary keys without losing out on too much performance.

Related to #4

Example: when this object is deleted from the parent, cascade the deletion to the store.

Are there use cases for this?

Add a defer cascade option to relationships. Sometimes we don't care about child models being deleted until the parent updates.

Also in this ticket: is this a valid assumption? Do we always want to force updates instead?

Currently, only class-based model storage is possible. It would be nice to provide a wrapper function or helper to seamlessly insert and query plain javascript objects.

This would require figuring out a story for storing the "name" attribute of objects, and figuring out how to apply constraints and indexes to the object shapes themselves. I'd rather not go with something like prop-types for this if possible.

Currently primaryKeys can only be of type string | symbol | number, due to usage in the native Map structure. It would be nice to specify (somehow) composite/complex primary key attributes.

Fast index scans would be a nice-to-have feature to ensure that the user can look up by index value quickly.

Questions to answer:

• Should indexing be allowed on foreign keys? It doesn't make sense for the current representation of the __meta__ attributes so we might have to refactor
• How should we store the index values? In a Map? Does a Splay Tree or Red-Black tree make more sense here? Need to do research

Constraint checks are widely used for debugging purposes, although not always. There should be an option for the user to specify that they want all constraint checks to be skipped.

This could be a foot-gun. I'm not sure that it's worth the configuration.

Enhancement of #6, add additional decorators to apply additional constraints to fields.

Relationship should not allow constraints

During development, mobstr should perform invariant checks to ensure certain properties are consistent. For example, primary keys should be present on all models.