DataObjects.Net v4.3.5 is released

Yesterday we have published DataObjects.Net v.4.3.5 build 6015.

What's new:

This build includes noticeably better DataObjects.Net reference:

• Help files are generated with the newest Sandcastle. The team behind it has fixed lots of issues after its previous release, so new help looks really better. Especially, lists of available extension methods - they're displayed properly now.
• We've added about 200 new class summaries and member descriptions, so help looks almost complete from this point now. There are just few non-essential gaps (e.g. some types from SQL DOM aren't documented).
• Finally, new help can be integrated into Visual Studio 2010 Documentation, so F1 will work everywhere. Choosing this option during installation is all you need to activate it.

Unfortunately, Manual wasn't updated yet, but this is the next logical step for us.

There are pretty large changes related to our Operations framework (i.e. activity logging), Session (mainly, events) and DisconnectedState:

All Session-level events were moved from Session itself to Session.Events member. So Session is much simpler now, especially from the point of IntelliSense. Actually, that was not the only reason to do this: you may find there is Session.SystemEvents member (also of SessionEventAccessor type). The rule is:

• System events are raised always - i.e. even when all custom logic is disabled (DirectSessionAccessor.OpenSystemLogicOnlyRegion does this). The typical case when custom logic must be disabled is deserialization (we do this automatically in this case). On the other hand, there can be some shared logic, that must operate even in this case - e.g. VersionValidator must still be able to detect version conflicts.
• "Normal" events are raised only when custom logic is enabled. This ensures normal services won't be operational in case when only system logic is enabled.

Other important changes related to Session type include:

• SessionOptions.AllowSwitching enables session switching necessity to use  Session.Deactivate() method. This question fully explains the case.
• Entity key remapping feature (actually, a feature of SessionStateAccessor) ensures new entities, which keys got new values on DisconnectedState.ApplyChanges() call, are transparently remapped to (associated with) their new keys. Earlier such entities were exposing themselves as removed ones after completion of ApplyChanges, and new entities became available. We changed this, since new behavior significantly simplifies data binding (subscription to PropertyChanged event, etc.). So now Entity instance may change its Key, although this is a very specific case.
• New overload of Session.NotifyChanged allows controlling its behavior more precisely.

Operations framework is redesigned to track and replay the operations in three modes:

• OperationLogType.SystemOperationsLog mode enables registration of system operations. This is the default mode now - mainly, because this mode is the simplest one.
• OperationLogType.OutermostOperationsLog mode enables registration of any outermost operations (user and system). Earlier operations framework was supporting just this mode. User operations aren't supported yet, but shortly this feature will be fully functional.
• OperationLogType.UndoOperationsLog mode - doesn't work yet, although there is pretty good basis to make it work soon as well.

This drawing explains the difference between first two modes:

DisconnectedState is extended as well. Now it:

• Utilizes new features of Operations framework - see its OperationLogType property.
• Provides OperationLogReplayFilter allowing to replay just some operations from the whole operation log. The left ones will stay there until the next ApplyChanges() method call.
• Has a set of AllXxx(...) methods allowing to enumerate cached entities, keys and associated states. In particular, DisconnectedState.All<TEntity>() method can be used to run LINQ-to-Enumerable queries over content cached in DisconnectedState now.
• Implements IEnumerable<Entity>.
• Provides useful GetPersistenceState(Key key) method.
• Has VersionProviderType and VersionProvider properties. Likely, you'll need the first one. It states indicates what kind of provider of versions must be queried after ApplyChanges() method call to refresh Versions content. Earlier DisconnectedState was refreshing it by its own content - the same behavior now can be activated by setting VersionProviderType to VersionProviderType.DisconnectedState. But current default value is VersionProviderType.Session - this mode ensures that versions will be grabbed from the server, but not from the local cache. So e.g. some server-side-only logic will set ModifyDate property somewhere, this won't lead to version check conflict further.
• Provides VersionsUsageOptions property allowing to control when automatic version checks are enabled.
• Provides VersionUpdateFilter delegate allowing to skip refreshes of some versions (e.g. version of read-only objects).

So new DisconnectedState is much more usable in real-life scenarios, and further we're going to implement few more features that will significantly simplify building of WCF applications with it.

Schema upgrade \ mapping layer was extended by:

• Support for default field values: use DefaultValue property of FieldAttribute to specify it. This feature currently doesn't work for composite keys (references to entities with composite keys).
  See issue 790.
• NullableOnUpgrade flag (in FieldAttribute as well). Useful, if you're upgrading nullable field to non-nullable - in this case you'll be able to access its NULL value in upgrade handlers, and e.g. replace them to some custom value (otherwise they'll be converted to DefaultValue or default(T)).
  See issue 791.

Also, we significantly improved Domain.Build(...) performance in case of upgrade - especially, in Skip mode: currently it is 2...3 times faster then before.

Finally, we refactored [Version] attribute support:

• New VersionMode enumeration allows to specify if the fields must be included into entity version, and if it is necessary to update (increment, or what's appropriate - currently non-overridable VersionGenerator.Next method decides this, but we may change this in future) its value automatically when entity is changed for the first time in new (outermost) transaction.
• One of consequences, except better clearness: earlier it was impossible to use multiple [Version] fields requiring automatic update in the same persistent type. Now you can use them - even together with other ones.

Updates and fixes:

There were lots of changes - I won't enumerate all of them here, but the most important ones are related to stability of schema upgrade layer. As far as I can judge, currently we've fixed all important bugs there.

Another significantly improved part is our LINQ translator - lots of reported bugs (mostly related to pretty complex or rare scenarios) were fixed there as well.

Also, there was pretty old issue related to support 64-bit version of ODP.NET (Oracle Data Provider). Thanks god, it was eliminated by Oracle. ODAC 11.2.0.1.2 (the most current version, and the one used by and DataObjects.Net 4.3.5) includes Oracle.DataAccess.dll assembly built for AnyCPU, so it is possible to use it on 64-bit platforms as well.

Btw, I noticed they started to provide provides XCopy-deployable installer in this version - although, as it was discovered, this isn't a complete true. It's necessary to run a special .bat file that will actually copy and configure all the binaries, and do few other manual steps. But anyway, this is a good option.

Some of fixes and improvements:

• .OrderBy with Enum fields doesn't work.
• Nullable Enum field cannot be set to null.
• Generic Structure descendant doesn't work.
• Upgrade issue: removal of property of EntitySet<T> Type along with T leads to exception.
• Registering abstract classes without inheritors
• Byte[] column upgrade issue
• Optimization: usage of INNER JOIN instead of LEFT JOIN when joining non-nullable reference fields.
• When schema upgrade fails, detailed information must be provided.
• Few issues related to installer were fixed as well.
• and so on. See the complete list of changes implemented in v4.3 branch for further details.

Changes in samples:

• OrderAccounting sample was significantly refactored - mainly, because of new DisconnectedState features and SessionOptions.AllowSwitching. It is much simpler now, but there are still few ugly places. May be the most annoying issue related to WCF support is necessity to manually include/exclude the entities from view model-related collections (normally - ObservableCollections acting as data sources for grids and lists; although our EntitySets support WPF notifications, they can be rarely used there directly) after creation or removal of such entities. Obviously, this can be fully automated with our rich set of events, and that's what we must do quite soon here. 
• WCF sample was also significantly updated - by the same reason.
• All our web samples (as well as web project template) are currently migrated to new ASP.NET 4 integrated mode web.config, but this brought mainly negative side effects. That's the only serious issue for beginners related to this version I know so far; likely, we'll switch to classic mode web.configs soon.

It seems that's all. Check out DataObjects.Net v.4.3.5 build 6015.