Add RemoveTypeHint with not existing type name

Result: InvalidOperationException "Type 'SomeTypeName' is not found."

I think that remove already removed type (or type that not existed at all) is safe action

DO 5.0.1

asked Aug 29 '14 at 02:30

Anton%20Guschin's gravatar image

Anton Guschin
73223035


One Answer:

Hello Anton.

It's complicated situation. There are two cases (or maybe more than two): 1)type was removed on previous upgrade and DO can skip that hint (your case) 2)user types name of type incorrectly and DO must tell him about that

And DO don't know which one in this time. And if DO will try to resolve this situation then user may receive unexpected result. DO expects that all hints, which user defines, have correct parameters (type name in this case). And DO only validates them to make sure that all actions with those parameters will finish correctly.

You can check that type exists in extracted model when you add some hint. Use UpgradeContext.ExtractedDomainModel or UpgradeContext.ExtractedTypeMap for that.

answered Aug 29 '14 at 07:28

Alexey%20Kulakov's gravatar image

Alexey Kulakov
45215

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

(Sep 02 '14 at 05:04) Anton Guschin Anton%20Guschin's gravatar image

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.

(Sep 03 '14 at 01:59) Alexey Kulakov Alexey%20Kulakov's gravatar image

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

(Sep 04 '14 at 05:47) Anton Guschin Anton%20Guschin's gravatar image

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.

(Sep 04 '14 at 06:36) Alexey Kulakov Alexey%20Kulakov's gravatar image

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?

(Sep 04 '14 at 06:50) Alexey Kulakov Alexey%20Kulakov's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

powered by OSQA