Persistence: Difference between revisions
Jump to navigation
Jump to search
Adamcolton (talk | contribs) No edit summary |
Adamcolton (talk | contribs) No edit summary |
||
| Line 26: | Line 26: | ||
[[Persistence Implementation]] | [[Persistence Implementation]] | ||
== External Indexing == | |||
One option to achieve indexing is to separate it from the core system. A data structure can fulfill the necessary interfaces for persistence and then that can act as the index. There just needs to be a listener to cause re-indexing. | |||
[[Category:Code]] | [[Category:Code]] | ||
Revision as of 16:12, 1 August 2018
This document is meant to build an abstract model of a persistence engine. I am specifically trying to avoid implementation details.
Also See
Persistence is complex. Goals are
- Data should move between memory and disk transparently
- Types can be migrated to add, remove or rename fields, change the type of a field or perform arbitrary changes via a migrate function.
Model
- The Store is collection of all records
- Every record has an ID unique to the store
- Every record has a Type that describes it's fields
- Index are an ordered subset of fields and allow O(m log n) look up of sets where m is the members of the set and n is type membership
- A record can have many indexes
- A record can belong to many categories
- A category can belong to many categories
- Models can reference each other
- Natural(ish) language searches can be performed efficiently
Resources
- https://blog.kowalczyk.info/software/volante/database.html
- https://en.wikipedia.org/wiki/Comparison_of_object_database_management_systems
- https://en.wikipedia.org/wiki/Object_database
External Indexing
One option to achieve indexing is to separate it from the core system. A data structure can fulfill the necessary interfaces for persistence and then that can act as the index. There just needs to be a listener to cause re-indexing.