Releases: mochidev/CodableDatastore
Version 0.2.4
Overview
This update fixes a race between read-only transactions and read-write transactions that could corrupt the current state of the datastore, losing saved data in the process. This was usually caught via assertions, but now reads and writes should be safer to perform side by side in complex transactions.
What's Changed
- Transaction Race Corruption by @dimitribouniol in #201
Full Changelog: 0.2.3...0.2.4
Version 0.2.3
Overview
This release fixes another issue with migrations where a migration may be stopped early if only an index was being modified.
What's Changed
- More Migration Fixes by @dimitribouniol in #199
Full Changelog: 0.2.2...0.2.3
Version 0.2.2
Overview
This release makes it easier to work with Optional index types, and fixes a rather glaring issue migrating a datastore with incompatible reference/secondary indexes.
What's Changed
- Optional Indexable by @dimitribouniol in #192
- Reference Migration Fix by @dimitribouniol in #194
Full Changelog: 0.2.1...0.2.2
Version 0.2.1
Overview
This release fixes some minor issues not caught in the initial release of Version 0.2.0:
- Fixed an issue where the Identifier type was not marked as public on DatastoreFormat.
- Added public typealiases for the Datastore types on the format.
- Added a more complete DatastoreFormat example.
What's Changed
- Format Fixes by @dimitribouniol in #190
Full Changelog: 0.2.0...0.2.1
Version 0.2.0
Overview
This update completely overhauls the interface for declaring indexes on your types, and is a breaking change. Please stay on 0.1.x if you can't upgrade at this time.
The major new type is DatastoreFormat, which you are encouraged to conform to in a struct, which provides the main version and type information that used to be generics on Datastore. This struct can then declare all the indexes rather than declaring them on the stored type instead, allowing types to more easily be re-used across repos, and allowing computed indexes to be much more expressive. Please see the documentation for DatastoreFormat for more details. Along with it come some new index types allowing relationships like many-to-many indexes to be indexed and retrieved using individual values rather than a set of them.
The next major update will likely change Indexable to be a proper protocol, no longer conforming to Codable and Comparable. Please look forward to that!
What's Changed
- Index Refactor by @dimitribouniol in #188
Full Changelog: 0.1.5...0.2.0
Version 0.1.5
Overview
This release shortcuts the lookups done with ranges that extend to the edge in either direction to speed up reads by not decoding indexes or identifiers for every instance to see if they are in range or not.
What's Changed
- Optimized Scanning by @dimitribouniol in #186
Full Changelog: 0.1.4...0.1.5
Version 0.1.4
Overview
This release enables easier use of datastores whose encoded items are enums identified by member names which would previously conflict, and updates all the accessors to return the previously persisted value where applicable.
What's Changed
- Disfavored Accessors by @dimitribouniol in #179
- Return Replaced Values by @dimitribouniol in #181
Full Changelog: 0.1.3...0.1.4
Version 0.1.3
Overview
This release fixes a bug loading ranges starting from entries that span page boundaries. It also adds a new deleteIfPresent() method that doesn't throw if the entry is missing.
What's Changed
- Broken Insertion Cursor by @dimitribouniol in #173
- Delete If Present Mutation Methods by @dimitribouniol in #174
Full Changelog: 0.1.2...0.1.3
Version 0.1.2
Overview
This release enhances the first use experience by no longer throwing errors when the first action performed is to check for the existence of an entry when nil might be expected instead.
What's Changed
- Todo Update by @dimitribouniol in #161
- Minor Type Cleanup by @dimitribouniol in #162
- Proper visionOS Support by @dimitribouniol in #167
- Loads From Fresh Datastores by @dimitribouniol in #166
Full Changelog: 0.1.1...0.1.2
Version 0.1.1
Overview
This release vastly improves the memory footprint of a DiskPersistence, keeping an upper-bound of resources in memory instead of every change that was made during a session. This was generally not an issue unless you were making 1000s of edits at a time, though it would consistently be a problem during migrations and warmups.
What's Changed
- Memory Efficiency by @dimitribouniol in #158
Full Changelog: 0.1.0...0.1.1