Hello Oleksandr,
We do that for a reason. Generally if version of assembly changes then there are some changes in it. DataObjects.Net cannot check what exactly has changed and what effect the changes may make on database so if versions differ you will get an error. I think you would prefer to get an exception instead of data damage which can be in DomainUpgradeMode.Perform. It is one more check which prevents you from that.
I will speak about the case when assembly contains only entities. so any change of than will affect database somehow.
You have such scenarios of upgrade:
1) 0.0.0.0(basically this means you have empty database) -> 1.0.0.0 . In that case you don't need to create any custom upgrade handlers.
2) 1.0.0.0 -> 1.0.0.0 - version is not changed so DataObjects.net considers that there is no changes in model and allows to continue building. No custom upgrade handler needed.
3) 1.0.0.0 -> 1.1.0.0. Something has changed in the assembly so as long as you need to save data in database you will need a custom upgrade handler. Lets say you renamed a field in one of entities. Custom upgrade handler might be like:
public class Upgrader : Xtensive.Orm.Upgrade.UpgradeHandler
{
public override bool CanUpgradeFrom(string oldVersion)
{
if (oldVersion==null)
return true; // database is empty so whatever.
var oldVersionInstance = Version.Parse(oldVersion);
//this handler can upgrade the assembly only form version 1.0.x.x to current
if (oldVersionInstance.Major==1 and oldVersion.Minor==0)
return true;
return false;
}
protected override void AddUpgradeHints(ISet<UpgradeHint> hints)
{
base.AddUpgradeHints(hints);
// this is the only difference between v1.0.x.x and the current assembly.
hints.Add(new RenameFieldHint(typeof (Person), "MidName", "Patronymic"));
}
}
You just can override CanUpgradeFrom() and return true or false by any algorithm you find reasonable. DataObjects.net gave you information and it is up to you how to use it.
answered
Apr 09 '19 at 10:15
Alexey Kulakov
772●2●5