Ok, I can check model using UpgradeContext.ExtractedDomainModel before add hint

But you mentioned unexpected result, this I don't understand Wrong remove type hint can't (mustn't) do anything with real data. Why exception?

Some common cases: If type was removed and hint correct, we will get domain without type and data.

If type was removed and hint incorrect, we will get InvalidOperationException, but should get error on build (unsafe action)

If type wasn't exist, we will get InvalidOperationException, but should get domain without already "unexisting" type and data

DO can't differ types which removed by user on previous upgrade, and types which never exist.

Hint is correct when all fields are correct. And when you specify name of type which doesn't exist then hint is incorrect.

DO generates some actions (manipulations with tables) based on hints. And DO must be sure that all hints are correct before creation of this actions. You, as customer, don't need that DO removes or replaces or do something else with your real data by accident. It's more safely to throw exception before DO will do some manipulations with real tables or columns.

DO shouldn't differ types Don't do anything and data can't be lost

Hm, if DO must not remove data by accident why this http://support.x-tensive.com/question/6097/removetypehint-for-not-removed-type not a bug?

For example I have many similar types with names like Type1, Type2, Type3 ... TypeN Then remove some types and add hints for all removed types

Misprint in one hint (Type7 instead Type8)

On build domain get error/unsafe action (because has wrong hint instead hint for removed type)

Naturally add hint for removed type and build

All ok, except one thing, data for Type7 will be removed

Hi Anton. I think we have a misunderstanding.

RemoveTypeHint tells DO that we removed some type in out model and DO must generate action to remove table associated with specified type from database. DO try to validate hint. For RemoveTypeHint, DO check that this type exists in extracted model. For example, user can have some ignored tables in database, which do not exist in extracted model. If we do not check that type exists in extracted model and name of type matches with ignored table then we can generate action that remove this ignored table. That i meant when i told about accident.

Let's continue.

About case when user mistakes when he types name of type in RemoveTypeHint and this name matches with another already existed type. So, DO is not God, and we can't predict all user's mistakes. User should control what he writes. Do you agree?

About http://support.x-tensive.com/question/6097/removetypehint-for-not-removed-type. There is a situation when you, for example, want to recreate some type in database for some reason. Why not? This case demonstrates how to do that. And again, why user does not control hints which he writes?