As you see, we do nearly the same, but using direct SQL commands. You might notice we use different upgrade stages here - that's because schema hints must be generated in the same stage when schema changes, but OnStage method is executed when domain is already built, i.e. after schema changes. That's why we use earlier stages here.

Upgrade way 3: RDBMS-independent, based on custom upgrade code

You may find that usage of direct SQL commands is actually an optimization in previous case. You can achieve the same with this OnStage code:

So I must use method 1 or 2, but I'd rather wait the development of an "TypeMerge" hint to do this : is it possible that you develop such an hint for next release? I've the feeling we'll get this migration case from time to time, and this UpgradeHint would very helpful.

ASP.NET MVC Sample creates ~ 100K instances on startup. It takes ~ 10 seconds on good PC, entity has several fields. I.e. entity creation performance is about 10K entities per second in case this is a hierarchy root.

So in this case it should take about 2.5-3 minutes to handle the migration using this method (it's better to do this in transactions processing ~ 10K entities at once). If you need a single transaction, timeouts can be adjusted to ensure it will be finished, but this will take more time in this case.

For now this isn't planned - frankly speaking, I'd prefer to postpone this until release of v4.5 beta (caching + likely, security). We're targeting to release it closer to new year.

That's a feature that really simplifies handling such cases, but since typical development pattern with DO is "develop, develop, develop, write a migration code, release", this is isn't what people strongly need in development, + there are workarounds like listed ones. I think it's better to bring few more features first...

I'll test method 3 that when I have the time. But how I can split the update in several transaction? In UpgradeHandler there is already an opened transaction for update, so should I do it outside UpgradeHandler?

By the way, the duration is not the only problem : if I create 1 million objects in one transaction wouldn't the transaction log grow to an huge size?

Another question: with method 3, how do you remove the instances of 'Derived' class?

In UpgradeHandler there is already an opened transaction for update, so should I do it outside UpgradeHandler?

No, you shouldn't, but you can control it: UpgradeContext.TransactionScope is the scope controlling upgrade transaction. So it must be completed & disposed to commit it; futher you can create & assign a new one there.

First version implies old B instanced are destroyed, but new A instances are created. I.e. if there were references to Bs, they'll be nullified. To keep them, you must manually write the code doing this in OnUpgrade method (i.e. finding all references pointing to old B instances and changing them to corresponding A instances). Btw, you can use ReferenceFinder to do this - it operates quite efficiently.

Second version does not recreate anything - it is purely hint-based solution. You don't need to keep [Recycled, Obsolete] public class B there.

Upgrade handler is a regular class inherited from Xtensive.Storage.Upgrade.UpgradeHandler, that must be registered in DomainConfiguration.Types - normally, as part of the whole assembly with persistent types.

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)!