Question

DO 5.0.20

Same as NullableOnUpgrade

http://support.x-tensive.com/question/6291/cannot-create-a-row-of-size-8061-which-is-greater-than-the-allowable-maximum-row-size-of-8060

With [Recycled] field every perform would execute (ADD/DROP COLUMN)

It is not needed, because on first perform upgraders was executed and field removed from DB

Next performs:

can not doing useful things, because column data is empty
should not use this column

Sample:

using System;
using Xtensive.Orm;
using Xtensive.Orm.Configuration;
using Xtensive.Orm.Upgrade;

class Program
{
    static void Main(string[] args)
    {
        var dc = new DomainConfiguration("sqlserver://localhost/DO40-Tests");

        // First run
        //dc.UpgradeMode = DomainUpgradeMode.Recreate;
        dc.UpgradeMode = DomainUpgradeMode.Perform;

        dc.Types.Register(typeof(Program).Assembly);

        using (var d = Domain.Build(dc))
        {
        }
    }
}

[HierarchyRoot]
[Serializable]
public class Table : Entity
{
    public Table(Guid id)
        : base(id)
    {
    }

    [Field, Key]
    public Guid Id { get; set; }

    [Field]
    [Recycled]
    public string Field { get; set; }
}

Accepted Answer

Hello Anton,

Sorry but we can't do that because otherwise we would intentionally break our mechanisms. And it is not good for product's stability and reliability.

Let's dive into internal processes of Domain building. Domain model building has following steps (if we simplify it):

get all registered types
build definitions (TypeDefs, FieldDefs, IndexDefs, etc.)
pass raw definitions to IModule.OnDefinitionsBuilt(BuildingContext, DomainModelDef) method for customer to make changes if he will
validate result definitions
build infos (DomainModel with TypeInfos, FieldInfos, IndexInfos, etc.). Any modifications of DomainModel after it is built are forbidden, the model becomes locked.

These steps are isolated have no idea about current database structure, more then that, by default they execute in parallel with database schema extraction.

Each TypeInfo and FieldInfo must be represented in database as table and column respectively. We should guarantee that, this is vital for stable work.

You also probably know that in Perform/PerformSafely upgrade modes we build two Domain models - one for upgrade (on Upgrading stage, you work with this model in UpgradeHandler.OnUpgrade() method) and another one as final model (included to the Domain instance you receive). And [Recycled] attribute on a field or a type basically says to include the field or the type into upgrading model and avoid including them to the final model. So the field or the type should be represented in database on Upgrading stage and should not when you receive Domain instance.

Now back to your suggestion, since we have no chance to avoid building FieldInfo for recycled field in upgrading model the only way is to not build assigned column. If we did that we would have the recycled field as FieldInfo but no column for it in database. We can't allow such desynchronized states of database and domain model.

Moreover, we don't know exact consequences of states being desynchronized but obviously nothing good will happen. Now, if a field is not represented in Domain model (and in database) you get expected and predictable exception telling you about absence, execution won't go further and that's great. With desychronized states this protection wouldn't work, a query translation, for instance would execute further and only God knows what exception you would have as result. This is unpredictable and really bad for you and for other customers.

Subscription:

Related questions