- i am making a change here so that to update / delete a material type - you should send the material type code instead of the material type id. i am also blocking edits if the MT is being used by items

At the moment, storing the material type name instead of ID presents the following problem. If I ...

• Create a material type (say, "Book")

• Assign it to several items (so there are four items of the "Book" type)

• and then try to delete the Book material type,
  the operation fails because Book is in use. That's good!

But if I then

• edit the "Book" type to have a different name (say, "Hardcover Book")

• and try to delete that material type
  the operation succeeds. The Book/Hardcover Book is now gone, but the items still have "Book" as a material type - one that no longer exists.

note that there is also a check that the code in the item actually exists in the material type table - if it does not - the insert (of the item) will fail

Hi Matt
I think we are saving a code - the material type in my opinion will grow to contain more data. What is stored in the item itself is a key - book , audio, video, journal, article, dvd, etc...
This key can be used to look up more info about the material type (not that there is any yet , but there will be) from the material table as the key is a unique index in the material table.
The advantage is that no join is needed to join between the item and the material type - the code can be used for i18n translation as it is a descriptive code. The record may be displayed in many languages and there will be no reason to display the code - this would be the case as well if an actual value was in the item - it would need to be i18n'ed
Look at this as a unique descriptive code that has UIusage (i18n) , and backend usage (unique index for lookups)
Point two is correct - there is a check if the code exists in any items

Does that make sense?

I have a couple of questions about this that I was asking about, but maybe it makes more sense to ask them here to get more people involved. I'm wondering:

1) Why are keys for things like material type and location being stored in the item model by name instead of ID? It seems to me that that would cause problems if the name of a material type were changed after being assigned to one or more item records. (This relates to the issue Mike raises in STRIPES-282.)

2) Does Jakub's comment above indicate that attempting to delete a material type will fail if the type is attached to any item record? If not, how is this enforced?