XAF – A Simpler Way to Check Database Compatibility (Coming soon in v15.2)

In earlier versions, to check the compatibility of an application and its database, a ModuleInfo table was created in the database. This table stores information on the module versions used in an application. When checking the compatibility of the database and the application, the versions stored in the ModuleInfo table are compared with actual module versions. A DatabaseVersionMismatch event occurs when there's a mismatch. By default, each module's version is set to "1.0.*" using the AssemblyVersion Attribute in the Properties\AssemblyInfo.cs file. The asterisk sign in the version indicates that the build and revision numbers in the version are autoincremented, and so version value is updated with each new build. As a result, WinForms and ASP.NET module versions may not be synced if you build WinForms and ASP.NET applications separately (e.g, when creating a ClickOnce installation or deploying to IIS).

With v15.2, we've introduced a new application and database compatibility check mode; one that utilizes native XPO methodologies. In this mode, the following checks are performed:

The database exists.

All required tables exist.

All required columns exist.

The DatabaseVersionMismatch event occurs if any of these checks fails.

The new XafApplication.CheckCompatibilityType property specifies which mode to use. The CheckCompatibilityType.ModuleInfo value indicates that the old mode that relies on the ModuleInfo table is used. This mode is still used by default for applications created with earlier versions of XAF. In applications created with the Solution Wizard in version v15.2, the XafApplication.CheckCompatibilityType value is CheckCompatibilityType.DatabaseSchema, which corresponds to the new mode detailed above. This property value can be changed in the Application Designer:

Note that the use of ModuleInfo is more complicated, but it ensures business logic compatibility in addition to data model compatibility. The new DatabaseSchema mode relies on the database schema only.

A CheckCompatibilityType property has also been added to the IObjectSpaceProvider interface, allowing you to specify the mode individually for each Object Space Provider (when you use multiple databases). By default, it is set to null and the XafApplication.CheckCompatibilityType value is actually used. Another useful change with this interface is the new IObjectSpaceProvider.SchemaUpdateMode property. You can now use it to specify handle compatibility checking for the database associated with the current Object Space Provider. The following values are available:

DatabaseAndSchema - Missing database is autocreated. The database schema is updated when the compatibility check fails.

None - Database compatibility issues are ignored.

=======================================

That's my last post prior to launch and hopefully you've liked what we've done with XAF. As always, we want to hear your thoughts. Please tell us what you think of XAF v15.2.

A nice change would be when using ModuleInfo mode to ignore (or downgrade) DevExpress assembly versions. Sometimes you guys put out a bad update that we don't catch before we put it out. If you have to roll back DX versions (i.e. from 15.1.7 to 15.1.6) this becomes a really big problem because the DX versions in the DB are higher. The ability to ignore those would be great.

28 November, 2015

John01

May be there should be a way to ignore when only new tables and fields are added as it should be considered backwards compatible with the existing code and so ignorable.

28 November, 2015

John01

@Nate Laff: I just delete existing ModuleInfo and let it be created again. Works in practice.

28 November, 2015

Nate Laff

That wouldn't work for me. I rely on the past module numbers in order to perform version specific upgrading.

I version my apps like this

<major>.<minor>.<dxversion>.<databaseversion>

So like 1.0.15170.999 (15170 = DX 15.1.7.0), 999 = DB version, which is the only number I look at while updating.

To delete that table for one offs would maybe work, but on the whole I couldn't do that. Especially with 500+ separate clients using the software, if even a fraction of them get an update that I later have to pull due to bad DX version it would be a nightmare (I know because I've done it)

29 November, 2015

Konstantin B (DevExpress)

@Nate Laff: You can delete only those ModuleInfo records that are related to XAF modules, rather than drop the entire ModuleInfo table. You can override the ModuleUpdater.UpdateDatabaseBeforeUpdateSchema in the following manner for this purpose: