Skip to content

Remove Create and Delete morph-type methods from MiniLcm API #2221

@myieye

Description

@myieye

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions