Conventional model keys
Chalarangelo opened this issue · 1 comments
Motivation
Too much configuration is arguably a bad thing. Convention over configuration is potentially better. Customizable model key names are not going to be particularly useful in the long run and raise a lot of potential issues.
Proposal
Entirely deprecate the key name customization mechanism. Instead of customizable key names, offer an id that is by default assigned to all models and is mandatory everywhere. This will simplify a lot of the code checks and make the code a lot faster to work with.
Deprecating the key definition presents the problem of key types and automation. While this can break a few schemas irreparably, it's not a major issue and we can safely handle it. Simply removing the option to create automatic keys and non-string keys resolves the issue. Automatic keys and keys that resemble numeric values are pretty easy to generate from a development perspective, so we'll leave it up to the users to come up with their own solution.
The way we see it, this will provide a unified way to tackle keys and give developers more incentive to seek freedom in how they generate keys for their records. If we find that this convention is particularly useful, we can always release a complementary package with some utilities for generating keys as we did before.
Considerations
This will span changes across the entire library. It will also cause a lot of API changes as we'll have to rename all instances of key and keys exposed to developers as id and ids respectively (e.g. in RecordSet).
Resolved in #35