Migrating from XPO v1 to v2006

The paragraphs below highlight the differences between versions 1.x and 2006.X. Take them into account when migrating to the new version to avoid any problems or unexpected behavior.

Namespaces

DevExpress.Data3.dll is now required for XPO to work. Many classes were moved to this library. Some of its classes are now in other namespaces. See the table below for details.

XPDeletedObject

The XPDeletedObject table is not used by XPO 2006.X. With most database servers, you will need to drop this table before using an XPO v1 database with XPO 2006.X. You may not be able to do this or have an easy way of doing this in the following cases:

• You use Jet (native Microsoft Access databases). In this case, you may leave everything as is, but we recommend dropping this table.
• You use Microsoft SQL Server. An upgrade script will be available so you can easily modify your databases.

Attributes

• The MapToAttribute is no longer available. Use PersistentAttribute(string mapTo) instead.
• It is no longer possible to map several object properties to the same database field. Instead, you should map only one of those properties. The rest should use the PersistentAliasAttribute(string aliasPropertyName) attribute instead of PersistentAttribute.

XPBaseObject Methods

• The signatures of some methods have been changed. Save, Reload and Delete are not virtual anymore. Override the OnXXXing and OnXXXed methods instead.
• Some methods have been renamed to provide a more intuitive and consistent development experience. For instance, Loading has been renamed to IsLoading, BeforeSave to OnSaving, AfterLoad to OnLoaded. The old methods are still available and have been marked with the ObsoleteAttribute so you will get a compiler warning allowing you to easily locate and modify any calls to them.

Automatic Object Reload

XPO v1 automatically reloads changed objects. To determine the change, it reads the database's OptimisticLock field value which is loaded with each query. XPO 2006.X allows you to disable automatic object reloading. It exposes two properties that control XPO's behavior in such cases: Session.OptimisticLockingReadBehavior and XpoDefault.OptimisticLockingReadBehavior. The default values of these properties provides the same behavior as in XPO v1. Note that we may change the default behavior later on. Thus, if your code depends upon this behavior, make sure to explicitly specify the desired behavior using the properties mentioned above.

Two additional behavior alternatives in XPO 2006.X are: throw an exception or simply ignore the change.

Deferred Database Updates

In XPO v1, the Session.BeginTransaction method call immediately starts a new database transaction. Calling Save for some objects within the transaction immediately saves the changes to the database. This blocks other users until the transaction ends. The behaviour of XPO 2006.X is completely different. It doesn't start a database transaction and doesn't save any changes when you call the methods mentioned above. It applies all changes to a database within a short database transaction that takes place when you call the Session.CommitTransaction method. There are no lengthy transactions anymore.

Most programs written with XPO v1 will work without any changes with XPO 2006.X and provide much better concurrency. The behavior will differ in case you need to filter data using the Session.FindObject method or XPCollection instance and need to take into account the changes made earlier within the same transaction. In XPO v1, you would get the actual data, since all changes are saved immediately. In XPO 2006.X, use a new XPCollection constructor overload with the original collection as one of the parameters to achieve the same results. Using this approach you can even apply changes without committing them to the database and then commit only those changes that match a particular criteria. This was impossible with XPO v1.

MSSqlConnectionProvider

This object introduces a new ObjectsOwner property that is set to "dbo" by default. This differs from how XPO v1 behaves - object ownership is determined by Microsoft SQL Server based on the user's login. To make XPO 2006.X behave like XPO v1, set the ObjectsOwner property to null (Nothing in Visual Basic).

Many-to-many Relations

Suppose you have a many-to-many relationship between two classes with auto-generated GUID key fields. In XPO 2006.X, the intermediate table will also have an auto-generated GUID key field. Thus, you will need to update the structure of your tables if you have such relations and plan to port your databases to XPO 2006.X.

Purge

Persistent objects are not created during purge process in XPO 2006.X. If your application depends on the behavior of XPO v1 (it tries to access such objects) you will need to re-write your code when migrating.

Remoting

XPBaseObject does not derive from MarshalByRefObject anymore. In most cases our new stateless DAL with remoting support will be enough to solve your tasks.

Below are the reasons for this change.

To put it simply: it was a mistake to ever have it that way. Consider the scenario where each XPO business object is derived from MarshalByRefObject. If such objects are queried from the database backend by way of an XPCollection, the result is a large number of server-side objects, which are referenced from the client that queried the data. When field values and/or methods on these objects are actually accessed, a huge number of calls must be transferred over the network - which is the one thing that should be absolutely avoided with .NET Remoting.

The important point of making an exposed interface as coarse-grained as possible is supported by many .NET Remoting specialists, like Ingo Rammer and Martin Fowler in his book Patterns of Enterprise Application Architecture (a slightly adapted version of the important chapter 7 is available here).

Our new approach to .NET Remoting support favors a very coarse-grained interface over the fine-grained one in the previous example. To facilitate this, we have made the interface IDataStore available, which can be exposed via .NET Remoting. The interface is coarse-grained as it has only four members, some of which are not called regularly in a typical application and all of which try to carry a bunch of information at once, as opposed to requiring several calls. What's more, this single point of exposure greatly simplifies the structure of an XPO application with .NET remoting. We believe that this approach will serve .NET Remoting developers much better.

ClearDatabase method

• This member supports the XPO internal infrastructure and is not intended to be used directly from your code.
• If regardless of the previous point you still use this method in applications (at your own risk), note the change in this method's behavior. In XPO v1 this method clears the contents of all tables. In XPO 2006.X it simply drops all the tables in the database.

XPOneToManyCollection and XPManyToManyCollection

There are no XPOneToManyCollection and XPManyToManyCollection classes in XPO 2006.X. If you need to use your own collection within an association, you can use XPCollection as a parent. For this purpose, use a new XPCollection constructor overload - XPCollection(Session session, object theOwner, XPMemberInfo refProperty).