... has been launched!
P.S.
In case you find anything that doesn't work as expected, please, get us informed.
Thanks in advance.
Sorry for keeping the silence - I really haven't been writing here for a while. Usually this means we're quite busy with some new stuff, and in this case this is absolutely true. We're working on two main features we're going to bring quite soon:
- DataObjects.Net v4.4 - it brings really dramatic changes; most important of them are described in the following part of this post.
- New, dedicated DataObjects.Net web site. We know we should do this much earlier, and now even our own patience is finished ;)
Some details:
Website
It is almost finished, and will be launched quite soon. Few screenshots:
 
 
Hopefully, you'll like it.
As I wrote, we implement a set of dramatic changes there, but mostly they are related to refactoring we planned for pretty long time. Most important changes there include:
- Elimination of most of of assemblies. We'll leave just Xtensive.Core, Xtensive.Aspects, Xtensive.Aspects.Weaver (not necessary to reference it) and Xtensive.Orm, so you should reference just 3 assemblies from your code. It's a result of significant internal refactoring + ILMerge.
- We're starting to use actual assembly version numbers from this release. All assemblies there are marked as v4.4.0.0 (their file versions reflect minor revisions and build numbers). Assembly versions will be changed on each significant API change. Project upgrade tool will help to automatically upgrade your projects to the new version.
- Namespace renaming:
Xtensive.Storage is split into Xtensive.Orm (most of classes you need are there now) + Xtensive.Storage;
Xtensive.Core.* are renamed to Xtensive.* (but Xtensive.Core itself is left as is);
Xtensive.Modelling become Xtensive.Core.Modelling;
Xtensive.Integrity is gone;
there are few other less important changes.
- Usage of Session.Current / Session.Demand() is optional now. This actually means explicit passing of Session is recommended now; old API fully works, but all such methods are marked as obsolete; there are new methods for any part of API that formerly relied on current Session (e.g. there is Session.Query.All<T>()). Automatic session activation on method call is optional now (this behavior is managed by one of SessionOptions flags); DO itself does not require it, but it can be used when it is convenient (e.g. this is still a recommended practice for web applications). We did this because of two issues:
a) We discovered people tend to think DO isn't designed for concurrent operations (such as passing persistent objects to another thread). Of course, this isn't true, but "current Session" concept makes a different impression. There were people stating it as one of blocking issues.
b) People used to different style, and finally we understood it's a bad idea to make them to study our own one.
c) The advantage of this style is really subjective. It hides the complexity, although people used to manage it by their own in this case. Moreover, it doesn't bring any essential advantages to us - i.e. actually, framework does not need this feature to be enough extendable and flexible.
d) This technique isn't friendly to new "async" and "await" in C# 5 (i.e. there shouldn't be async methods in SessionBound descendants), so its usage must be 100% optional.
- SessionOptions brings 3 pre-defined combinations of flags now: ClientProfile, ServerProfile and LegacyProfile. Legacy profile is the mode you use now. Server profile is legacy profile without automatic session activation (since now this is optional). And finally, there is a client profile: each Session operating in this mode is created along with attached DisconnectedState, so it works nearly as DataContext in EF or Session in NH (from many points - even better). This mode allows people using different ORM frameworks to migrate to DO a bit easier.
- Xtensive.Practices is finally separated there. Btw, it will be shipped with full source code.
All above changes are mainly related to API. But certainly, this isn't all:
- We've actualized Manual. Btw, it's split in multiple topics in help, so it's much easier to study it there.
- Samples are now organized by technology. Also, they don't require IIS and installation of "IIS Metabase and IIS 6 configuration compatibility" components for Windows to be executed from VS.NET. Sandbox projects are moved to samples. Finally, there is a good Readme.htm that fully explains how to create a sample database, compile and and run them.
- We'll ship a set of .RAR archives allowing to download only necessary part of each build (e.g. just binaries). Actually, we already are.
All these changes (along with the dedicated web site) must make the product much more user-friendly - especially, for its adopters.
v4.4 will be released during November.
We're pushing the development of DataObjects.Net in two directions:
- Adding new and unique features and APIs. That's what distinguishes us from others. Frankly speaking, we've paused our activity here for a certain period, so our near-time goal is to push this part forward.
- Adding old and widely adopted features / APIs. That's what makes DO easier to study and more compatible with others. We must propose an alternative to nearly any nice feature available in competing products.
As you see, initial release of v4.4 is mostly focused on initial user experience and compatibility / similarity with competitors, but its subsequent updates (v4.4.X) will be devoted mainly to extensions.
Our further (pretty near) plans include:
- Implementation of a small framework simplifying MVVM development with DO. The description is here (a bit outdated).
- Implementation of access control / security extension - the preliminary description is here.
This update includes a set of bugfixes; probably, the most important one is multithreading bug in prefetcher.
IMPORTANT, PLEASE READ CAREFULLY:
1. You must upgrade to this version, if your trial is expired today. A hard-coded limitation of operational period is extended to February 1st, 2011 in this version. Certainly, this is related to trial version only. 60-day expiration of trial version is still intact.
2. It's strongly recommended to change just DataObject.Net assemblies while upgrading to this version. You must run the upgrade in PerformSafely or Perform mode.
3. We've fixed issue 813 in this version; the issue affects on default mapping. So if you used:
- [TableMapping] attribute on any of tables with EntitySets describing many-to-many relationships with automatically mapped intermediate item (e.g. Book.Authors and Author.Books),
- or used [FieldMapping] on such EntitySet fields (this didn't work earlier, but now this works),
you must:
- Back up your database before upgrade to this version. Count the number of tables there.
- Manually rename the tables where intermediate items for such EntitySets are stored accordingly with new mapping rules. Old table name is "OwnerTypeName-PropertyName-ItemTypeName", new table name is "OwnerTableName-PropertyMappingName-ItemTableName".
- Upgrade the Domain and count the number of tables there. If it's the same, and tables of intermediate items aren't empty, the upgrade was successful.
The new installers can be found in Downloads section.
|
|
