Published by marco on
The summary below describes major new features, items of note and breaking changes. The full list of issues is also available for those with access to the Encodo issue tracker.
In beta1, we read about changes to configuration, the data driver architecture, DDL commands, and security and access control in web applications.
In beta-2, we made the following additional improvements:
IApplication
, ICoreApplication
and IMetaApplication
. (QNO-4789, QNO-4788, QNO-4786, QNO-4785, QNO-4671, QNO-4669, , QNO-4668, QNO-4667, QNO-4660)ICustomCommandBuilder
. This was added by customer request, for applications that formulate queries that are beyond what the Quino ORM is currently capable of mapping. A blog post with more detail on how this works is forthcoming. (QNO-4802)DataContract
and DataMember
attributes in metadata and generated code. (QNO-4823, QNO-4826)This release addressed some issues that have been bugging us for a while (almost 3 years in one case).
You will not be missed.
As we’ve mentioned before, this release is absolutely merciless in regard to backwards compatibility. Old code is not retained as obsolete Obsolete
. Instead, a project upgrading to 2.0 will encounter compile errors.
That said, if you arm yourself with a bit of time, ReSharper and the release notes (and possibly keep an Encodo employee on speed-dial), the upgrade is not difficult. It consists mainly of letting ReSharper update namespace references for you. In cases where the update is not so straightforward, we’ve provided release notes.
One of the few things you’ll be able to keep (at least for a minor version or two) is the old-style generated code. We made this concession because, while even a large solution can be upgraded from 1.13.0 to 2.0 relatively painlessly in about an hour (we’ve converted our own internal projects to test), changing the generated-code format is potentially a much larger change. Again, an upgrade to the generated-code format isn’t complicated but it might require more than an hour or two’s worth of elbow grease to complete.
Therefore, you’ll be able to not only retain your old generated code, but the code generator will continue support the old-style code-generation format for further development. Expect the grace period to be relatively short, though.
Regardless of whether you elect to keep the old-style generated code, you’ll have to do a little bit of extra work just to be able to generate code again.
Before you can regenerate, you’ll have to manually update your previously generated code in the main model file, as shown below.
static MyModel()
{
Messages = new InMemoryRecorder();
Loader = new ModelLoader(() => Instance, () => Messages, new MyModelGenerator());
}
public static IMetaModel CreateModel(IExtendedRecorder recorder)
{
if (recorder == null) { throw new ArgumentNullException("recorder"); }
var result = Loader.Generator.CreateModel(recorder);
result.Configure();
return result;
}
// More code …
/// <inheritdoc/>
protected override void DoConfigure()
{
base.DoConfigure();
ConfigurePreferredTypes();
ApplyCustomConfiguration();
}
static MyModel()
{
Messages = new InMemoryRecorder();
Loader = new ModelLoader(() => Instance, () => Messages, new MyModelGenerator());
}
public static IMetaModel CreateModel(IExtendedRecorder recorder)
{
if (recorder == null) { throw new ArgumentNullException("recorder"); }
var result = Loader.Generator(MyModel)new MyModelGenerator().CreateModel(
ServiceLocator.Current.GetInstance<IExpressionParser>(),
ServiceLocator.Current.GetInstance<IMetaExpressionFactory>(),
recorder
);
result.ConfigurePreferredTypes();
result.ApplyCustomConfiguration();
return result;
}
/// <inheritdoc/>
protected override void DoConfigure()
{
base.DoConfigure();
ConfigurePreferredTypes();
ApplyCustomConfiguration();
}
In the application configuration for the first time you generate code with Quino 2.0, you should use:
ModelLoader = MyModel.Loader;
this.UseMetaSimpleInjector();
this.UseModelLoader(MyModel.CreateModel);
After regenerating code, you should use the following for version-2 generated code:
ModelLoader = MyModel.Loader;
this.UseMetaSimpleInjector();
this.UseModelLoader(MyModelExtensions.CreateModelAndMetadata);
…and the following for version-1 generated code:
ModelLoader = MyModel.Loader;
this.UseMetaSimpleInjector();
this.UseModelLoader(MyModel.CreateModel);
As you can see, we’ve already done quite a bit of work in beta1 and beta2. We have a few more tasks planned for the feature-complete release candidate for 2.0
Move the schema-migration metadata table to a module.
The Quino schema-migration extracts most of the information it needs from database schema itself. It also stores extra metadata in a special table. This table has been with Quino since before modules were supported (over seven years) and hence was built in a completely custom manner. Moving this support to a Quino metadata module will remove unnecessary implementation and make the migration process more straightforward. (QNO-4888)
Separate collection algorithm from storage/display method in IRecorder
and descendants.
The recording/logging library has a very good interface but the implementation for the standard recorders has become too complex as we added support for multi-threading, custom disposal and so on. We want to clean this up to make it easier to extend the library with custom loggers. (QNO-4888)
Finish integrating building and publishing NuGet and symbol packages into Quino’s release process.
And, finally, once we have the assemblies split up to our liking, we’ll finalize the Nuget packages for the Quino library and leave the direct-assembly-reference days behind us, ready for Visual Studio 2015.
(QNO-4376)
That’s all we’ve got for now. See you next month for the next (and, hopefully, final update)!