Pre-Defined Entities

[justin-millman]

A "Pre-Defined Entity" is essentially a rich enumeration:

public sealed class Month {
    [PrimaryKey] public string FullName => fullNames_[index_];
    public string Abbreviation => abbreviations_[index];
    public int NumDays => numDays_[index_];

    public static Month January { get; } = new Month(0);
    public static Month February { get; } = new Month(1);
    // other months

    private Month(int index) { index_ = index; }

    // private static arrays for the state
}

This is just an example, they can be implemented in a bunch of different ways. The keys here are:

1. The class has public static instances of itself; these are the Entity instances
2. The class is not necessarily reconstitutable; that's okay, because all the state is hard-coded

The rest of Translation behaves as normal. Other Entity types can reference the Pre-Defined Entity, and that data gets stored as a Reference. Pre-Defined Entities can have single- or multi-field Primary Keys, can have Candidate Keys, can have nullable fields, etc. Properties in a Pre-Defined Entity can be marked as [CodeOnly]; they can also be marked as [Calculated], though it's redundant (not an error).

Conceptually, the instances of a Pre-Defined Entity should never mutate, because the data won't be loaded from the database. Therefore, we only need to store the data in the back-end database once (when the database is created), but it's not inherently wrong to perform an overwrite. (That's something that will become clearer when the Transaction Layer is implemented.)

I don't think this is urgent, definitely just nice-to-have. It only provides a little bit of clear marking, you can do everything as above with the existing design, you just have to have a viable constructor that takes all the individual fields' values (rather than the indexing trick as shown above).