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:
Sample:
|
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):
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. |