See: #2192 (comment)
My comment with Jason's response regarding whether we need to anticipate missing or non-canonical morph-types:
His reply:
After some research the surprising (to me) answer is that the morpheme type list has been static in number and guid since it was introduced into the project template. Currently users can not modify that list. So I think that you can make that assumption. The consequences of some historical bug or feature that allowed the list in a project to be modified would be that any deleted items from the template would appear (no real problems) and that custom items would be deleted (big problems). So I would recommend at least adding a DeleteMorphType operation that throws an ugly exception for user safety.
There are a couple places we could add an "ugly exception":
- When we map a LibLCM entry to a MiniLCM entry and find a non-null and non-canonical morph-type
- When we're diffing morph-types while syncing and find a morph-type that needs to be added or deleted
What are your thoughts on this?
Ultimately creating morph-types definitely doesn't make sense, because we prepopulate them in the DB and the enum column is both required and unique, so it's impossible to create a new one.
See: #2192 (comment)
My comment with Jason's response regarding whether we need to anticipate missing or non-canonical morph-types: