DataObjects.Net Team Blog

DataObjects.Net 4.4.2 RC 2 is published

2012-02-09T20:48:00.002+06:00

Today we are releasing DataObjects.Net 4.4.2 RC 2. The main advantage of DataObjects.Net v4.4.2 branch is migration to the latest version of PostSharp library (v2.1) that significantly improves compilation speed.

List of changes comparing to DataObjects.Net 4.4.2 RC 1:

Fixed: Query translation error : group by with key of generic type
Fixed: Bug with type cast if use Contains() method
Fixed: DirectSqlAccessor.CreateCommand doesn't bind it to transaction
Fixed: Memory leak when using compiled queries
Improved: Tuple.Format() and TupleDescriptor.Parse() methods are up to 4x faster
Fixed: Sorting in subqueries is omitted under certain conditions
Added: Option to disable inclusion of SQL text in thrown exceptions
Fixed: Legacy methods Query.Execute() don't work as expected
Updated: PostSharp is updated to 2.1.5.12 version
Fixed: Syntactic sugar (shortcuts) in Prefetch API doesn't work
Fixed: Documentation contains outdated information
Improved: Project upgrade tool is reworked

Migration path

Note: If a previous version of DataObjects.Net was installed (via installer), uninstall it and install the current version of DataObjects.Net. The easiest and recommended way is to utilize our ProjectUpgrader tool which resides in %DataObjectsInstallationPath%\Common\ProjectUpgrader directory. Select a project and hit "Run" and that's it.

However, you may also try to update the project file manually. To do that, update references to the latest DataObjects.Net components as well as to PostSharp library. When it is done, the project should reference Xtensive.Aspects.dll, Xtensive.Core.dll, Xtensive.Orm.dll version 4.4.2.0 and PostSharp.dll version 2.1.0.0

Where to download

DataObjects.Net 4.4.2 RC 2 is published and can be downloaded from the download area.

DataObjects.Net Extensions, part 2. Reprocessible tasks

2012-01-11T16:19:00.000+06:00

This is the second part of the series of posts about DataObjects.Net Extensions, created and maintained by Alexander Ovchinnikov, the author of LINQPad provider for DataObjects.Net.
The first part was about batch server-side update and delete operations and this one is dedicated to reprocessible operations support.

Reprocessible operations

In multi-threaded environment, especially under high load there are pretty good chances of deadlocks, update conflicts, unique constraint violations, etc. Obviously, such cases must be correctly handled and this is where reprocessible tasks take up the challenge.

Which tasks are reprocessable?

Reprocessible task should represent an autonomous block of logic, usually a single method or a delegate so it potentially could be executed as many times as needed in case of failure.
Reprocessible task must be transactional, so it shouldn't change the state of the system unless it is successfully completed. Moreover, it shouldn't spoil outermost transaction if any.
Reprocessible task should be smart enough to join active session (if present) or initialize its own one.

A simple reprocessible task might look like this:

Domain.Execute(session =>
  {
    // Task logic
  });

Note Action<Session> argument. This is required to have the ability to join current Session or open a new one. However, this sort of declaration doesn't provide any way to manage conditions of reproccesibility and the transaction isolation level to follow. Overloads of the Domain.Execute extension method with full list of arguments provide such options:

void Execute(IsolationLevel isolationLevel, 
             IExecuteActionStrategy strategy, 
             Action<Session> action);

T Execute<T>(IsolationLevel isolationLevel,
             IExecuteActionStrategy strategy,
             Func<Session, T> action);

An implementor of IExecuteActionStrategy is capable of how to react to exceptions thrown, how many attempts to execute the task to make and so on.

Task execution strategies

There are dozens of ways how to execute the tasks, that's why the strategy is an interface; you may want to implement your own strategy for some specific scenarios. However, DataObjects.Net Extensions contains several ready-to-use strategies for the most common cases:

HandleReprocessableExceptionStrategy
HandleUniqueConstraintViolationStrategy
NoReprocessStrategy

HandleReprocessableExceptionStrategy

The strategy is used to handle any ReprocessibleException, which in turn is a erroneous situation that can be recovered by rolling back active transaction and reprocessing all actions in a new one. This strategy is applicable for the majority of scenarios and is recommended as a default one.

Domain.Execute(
    ExecuteActionStrategy.Reprocessable,
    session =>
        { 
            // do some stuff
        });

The default instance of HandleReprocessableExceptionStrategy can be accessed via ExecuteActionStrategy.Reprocessable static property. Default number of attempts is 5.

HandleUniqueConstraintViolationStrategy

The strategy is used to handle either ReprocessibleException or UniqueConstraintViolationException as latter one doesn't inherit ReprocessibleException. The strategy extends HandleReprocessableExceptionStrategy and might be especially helpful in scenarios "Add or Update entity".

Domain.Execute(
    ExecuteActionStrategy.UniqueConstraintViolation,
    session =>
        { 
            var counter = session.Query.SingleOrDefault<Counter>(ID);
            if (counter == null) {
                counter = new Counter(session, ID);
            }
            counter.Value++;
        });

The default instance of HandleUniqueConstraintViolationStrategy can be accessed via ExecuteActionStrategy.UniqueConstraintViolation static property. Default number of attempts is 5.

NoReprocessStrategy

This strategy doesn't support reprocessing. It should be used in scenarios where reprocessing is not desirable or might lead to erroneous results, for example, a task operates with non-transactional objects or services:

Domain.Execute(
    ExecuteActionStrategy.NoReprocess,
    session =>
        { 
            // on transaction rollback results of these methods can't be reverted
            SendMail();
            CreateAFile();
            DeleteAFile();
            // database-related actions
        });

The default instance of NoReprocessStrategy can be accessed via ExecuteActionStrategy.NoReprocess static property.

Custom reprocessible strategies

To utilize your own reprocessible strategy, use this pattern:

Domain.Execute(
    new MyFancyReprocessibleStrategy(),
    session =>
        { 
            // some actions
        });

The implementation of custom reprocessible strategy might be based on ExecuteActionStrategy class which is the base class for the above-mentioned strategies and is included into DataObjects.Net Extensions or can be made from scratch.

Enjoy the power of DataObjects.Net Extensions, employ server-side batches and task reprocessing in your projects.

P.S.
How to install the extension is described in the first part.

DataObjects.Net is migrated to PostSharp 2.1

2011-12-29T21:04:00.000+06:00

As it was announced earlier, right after the release of DataObjects.Net 4.4.1 the project was migrated to PostSharp 2.1. According to the PostSharp 2.1 release notes, one of many positive changes of the migration is noticeable compile-time performance boost.

For example, after the migration a DataObjects.Net tests project with hundreds of models is being compiled 2 times faster. I hope you'll notice the same effect. Say thanks to Gael, the author of PostSharp for such a sweet update.

Changes

This version of DataObjects.Net contains all new features and bugfixes from the previous version, the only difference is that the project is migrated from PostSharp 2.0 to PostSharp 2.1.

Migration path

If a previous version of DataObjects.Net was installed (I mean through installer), uninstall it and install the current version of DataObjects.Net.
In your projects update references to the latest DataObjects.Net components as well as to PostSharp library.

Now your projects should reference Xtensive.Aspects.dll, Xtensive.Core.dll, Xtensive.Orm.dll version 4.4.2 and PostSharp.dll version 2.1.

Where to download

DataObjects.Net 4.4.2 is published as a release candidate and can be downloaded from the download area.

Big Winter Sale

The sale is going to its end, as 2011 year does. So if you are still thinking, these are the last days to lock your savings. Till the end of 2011 year we are offering 50% off. Beyond the great product, you're also gaining 1 year of fast and professional support, new releases, nightly builds and more.

P.S.
This is likely to be the last post in this year.
I'm wishing you a wonderful 2012 year, full of hope and optimism.

DataObjects.Net v.4.3.8 & v.4.4.1 are released

2011-12-19T19:14:00.000+06:00

Today, 19th December, 2011 we are announcing the final release of DataObjects.Net 4.3.8 and 4.4.1, available for download on our web site.

Changes in this version are listed in these posts:

What's next?

As it was promised, the next version in 4.3 & 4.4 branches will be migrated to PostSharp 2.1 RTM. All the functionality will be the same, except the version of PostSharp. It is expected that the next version will be ready within a week or two.

Setting default values for persistent properties

2011-12-13T18:43:00.000+06:00

While DataObjects.Net 4.4.1 & 4.3.8 Final installers are being prepared and tested, here is one more post about one not so well known feature of effective domain modelling and how that feature is extended in the upcoming release.

DataObjects.Net includes a set of rules for defining the default value for a persistent property.
The rules are the following:

Let T is the type of a persistent property, then:

1. T is a primitive type

If T is a primitive type, Guid or String then the default value for the property is default(T) and the type of the underlying column is T.

public class Animal : Entity {
...
[Field]
public int Age { get; set; }

CREATE TABLE Animal (
...
[Age] [int] NOT NULL

2. T is Nullable<>

If T is Nullable<> then the default value is NULL and the type of the underlying column is Nullable T.

public class Animal : Entity {
...
[Field]
public int? Legs { get; set; }

CREATE TABLE Animal (
...
[Legs] [int] NULL

3. T is a reference type

If T is a reference type then the default value is NULL and the type of the underlying column is the type of primary key of the referenced Entity.

public class Animal : Entity {
...
[Field]
public Person Owner { get; set; }

CREATE TABLE Animal (
...
[Owner.Id] [int] NULL

These rules are more or less obvious and straightforward but what if the overwhelming majority of animals in your application universe have 4 legs and you don't want to set this property manually again and again? Or there should not be homeless animals? Then I guess, you should have the opportunity to override these rules.

This can be done with the help of [Field] attribute.

1. Setting default value for a primitive persistent property

public class Animal : Entity {
...
[Field(DefaultValue = 4)]
public int? Legs { get; set; }

CREATE TABLE Animal (
...
[Legs] [int] NULL
...
ALTER TABLE [dbo].[Animal] ADD CONSTRAINT [DF_Animal_Legs]  DEFAULT ((4)) FOR [Legs]

2. Changing nullability of a reference field.

public class Animal : Entity {
...
[Field(Nullable = false)]
public Person Owner { get; set; }

CREATE TABLE Animal (
...
[Owner.Id] [int] NOT NULL

This setting leads to NOT NULL column which means that the value of the property must be set prior to any Session.Persist() call while constructing the Animal entity. Therefore, the right way to set such properties is inside entity's constructor, before executing any queries.

3. Setting default value for a reference persistent property.

Note, this feature is implemented in the upcoming version of DataObjects.Net (by upcoming I mean 4.3.8 or 4.4.1 branches).

public class Animal : Entity {
...
[Field(DefaultValue = 1)]  // 1 here is the key of the default animal owner
public Person Owner { get; set; }

CREATE TABLE Animal (
...
[Owner.Id] [int] NULL
...
ALTER TABLE [dbo].[Animal] ADD CONSTRAINT [DF_Animal_OwnerId]  DEFAULT ((1)) FOR [Owner.Id]

This makes sense in a scenario when the key of the default referenced entity is already known on a compilation step or it is a well-known constant identifier so there is an Entity with that key in the domain.

I hope these little tricks will help you in modelling your domains with even less efforts.

DataObjects.Net 4.3.8 & 4.4.1 Release Candidates 2 are out

2011-12-05T20:45:00.000+06:00

DataObjects.Net 4.3.8 RC 2 & 4.4.1 RC 2 are available for download.

This release includes a minor fix in SQL Server & Oracle providers. No special actions for migration to the new version are required except updating the references.

Just as a reminder: the list of fixes, updates and new features is here, the detailed overview of index management-related features is here.

We are waiting for your feedback! Write to support@x-tensive.com.

Thank you!

Big Winter Sale

2011-12-01T16:02:00.000+06:00

We are glad to announce that Big Winter Sale has started on the 1st of December and will last till the end of the year. During this time you get 50% off any edition of DataObjects.Net and Help Server. To apply this 50% special to your order, just enter DEC2011PROMO coupon code at the shopping cart or product checkout page.

Should you have any questions, please email to sales@x-tensive.com.

Sincerely,
Xtensive.com Sales Team

DataObjects.Net 4.3.8 RC 1 & 4.4.1 RC 1 are published

2011-11-28T17:38:00.000+06:00

Today DataObjects.Net 4.3.8 RC 1 & DataObjects.Net 4.4.1 RC 1 are published and available for download.

Just as a reminder: the list of fixes, updates and new features is here, the detailed overview of index management-related features is here.

No special actions for migration to the new version are required except updating the references.

We are waiting for your feedback! Write to us to support@x-tensive.com.

Thank you!

DataObjects.Net 4.5 Beta 4 binaries are updated

2011-11-24T18:22:00.001+06:00

DataObjects.Net 4.5 Beta 4 package is updated to the latest revision, incorporating all the fixes and features from branches 4.3 & 4.4. The updated binaries can be downloaded from here.

DataObjects.Net Extensions, part 1

2011-11-21T13:54:00.000+06:00

I'm writing this post on behalf of Alexander Ovchinnikov who is the author of DataObjects.Net Extensions project. Earlier Alexander developed LINQPad provider for DataObjects.Net, which is included into standard DataObjects.Net installation package starting from version 4.5, so he is deservedly one of the most productive contributors in DataObjects.Net community.

This project is officially called DataObjects.Net Extensions and is distributed under MIT license. Source code is available on github. The latest version of DataObjects.Net Extensions contains 2 main set of features:
- Batch server-side update and delete operations
- Operation reprocessing

In this post I'll describe the first part, batch server-side update and delete operations.

How to install the extension

1. The extension is distributed in a form of NuGet package, so to use it you should install NuGet Manager if you haven't installed it already. As far as I know, Visual Studio 2010 SP 1 already includes this manager by default.

2. Open the desired solution and in the context menu select "Manage NuGet packages..."

3. Search for "DataObjectsExtensions" package

4. Click "Install", choose projects to add the reference to and click "OK".

5. Check that the package is successfully installed and start using it.

Sample domain model

This model will be used in code samples.

[HierarchyRoot]
    public class Bar : Entity {

        public Bar(Session session) : base(session){}

        [Field, Key]
        public int Id { get; set; }

        [Field]
        public string Name { get; set; }

        [Field]
        public int Count { get; set; }

        [Field]
        public string Description { get; set; }
    }

    [HierarchyRoot]
    [Index("Name", Unique = true)]
    public class Foo : Entity{

        public Foo(Session session) : base(session){}

        public Foo(Session session, int id) : base(session, id){}

        [Field, Key]
        public int Id { get; set; }

        [Field]
        public string Name { get; set; }

        [Field]
        [Association("Foo")]
        public Bar Bar { get; set; }
    }

Batch server-side operations

Why they are important?

Well, Captain Obvious to the rescue, sometimes there could be a scenario when a set of records needs to be updated without fetching them on client. There might be various reasons for that such as performance issues, limitations of business logic, etc. In such cases users have to utilize old good plain SQL to execute "UPDATE" or "DELETE" commands via underlying ADO.NET providers. But while this is not always convenient, this also could lead to potentially erroneous results because as soon as domain model changes, it becomes out of sync with these SQL commands.

DataObjects.Net Extensions sorts out the problem providing a set of IQueryable extension methods that are translated to the desired UPDATE or DELETE commands. For instance:

Query.All<Bar>()
  .Where(a => a.Id == 1)
  .Set(a => a.Count, 2)
  .Set(a => a.Name, a => a.Name + "suffix")
  .Update();

Listed below are some scenarios which you might encounter while using the package. Every case is followed by the corresponding translation to SQL.

Updating persistent property with constant value

Query.All<Bar>()
  .Where(a => a.Id == 1)
  .Set(a => a.Count, 2)
  .Update();

is translated to:

DECLARE @p0 Int SET @p0 = 2
UPDATE [dbo].[Bar]
SET [Count] = @p0
FROM [dbo].[Bar] AS j0 INNER JOIN (
SELECT
  [a].[Id]
FROM
  [dbo].[Bar] [a]
WHERE
  ([a].[Id] = 1)
) AS j1 ON (j0.[Id] = j1.[Id])

Updating persistent property with expression, computed on server

Query.All<Bar>()
  .Where(a => a.Id==1)
  .Set(a => a.Count, a => a.Description.Length + a.Count * 2)
  .Update();

is translated to:

UPDATE [dbo].[Bar]
SET [Count] = ((DATALENGTH([Description]) / 2) + ([Count] * 2))
FROM [dbo].[Bar] AS j0 INNER JOIN (
SELECT
  [a].[Id]
FROM
  [dbo].[Bar] [a]
WHERE
  ([a].[Id] = 1)
) AS j1 ON (j0.[Id] = j1.[Id])

Setting a reference to an entity that is already loaded into Session

// Emulating entity loading
var bar = Query.Single<Bar>(1);

Query.All<Foo>()
  .Where(a => a.Id == 2)
  .Set(a => a.Bar, bar)
  .Update();

is translated to:

DECLARE @p0 Int SET @p0 = 1
UPDATE [dbo].[Foo]
SET [Bar.Id] = @p0
FROM [dbo].[Foo] AS j0 INNER JOIN (
SELECT
  [a].[Id]
FROM
  [dbo].[Foo] [a]
WHERE
  ([a].[Id] = 2)
) AS j1 ON (j0.[Id] = j1.[Id])

Setting a reference to an entity that is not loaded into Session, 1st way

Query.All<Foo>()
  .Where(a => a.Id == 1)
  .Set(a => a.Bar, a => Query.Single<Bar>(1))
  .Update();

In this case DataObjectsExtensions are smart enough to extract the value of key from Query.Single method argument and use that value in command translation:

DECLARE @p0 Int SET @p0 = 1
UPDATE [dbo].[Foo]
SET [Bar.Id] = @p0
FROM [dbo].[Foo] AS j0 INNER JOIN (
SELECT
  [a].[Id]
FROM
  [dbo].[Foo] [a]
WHERE
  ([a].[Id] = 1)
) AS j1 ON (j0.[Id] = j1.[Id])

All overloads of Query.Single, Query.SingleOrDefault methods are also supported.

Setting a reference to an entity that is not loaded into Session, 2nd way

Query.All<Foo>()
  .Where(a => a.Id == 1)
  .Set(a => a.Bar, a => Query.All<Bar>().Single(b => b.Name == "test"))
  .Update();

is translated to:

UPDATE [dbo].[Foo]
SET [Bar.Id] = (SELECT TOP 1 [a].[Id] FROM [dbo].[Bar] [a] WHERE ([a].[Name] = N'test'))
FROM [dbo].[Foo] AS j0 INNER JOIN (
SELECT
  [a].[Id]
FROM
  [dbo].[Foo] [a]
WHERE
  ([a].[Id] = 1)
) AS j1 ON (j0.[Id] = j1.[Id])

All overloads of Queryable.Single, Queryable.SingleOrDefault, Queryable.First, Queryable.FirstOrDefault methods are supported.
Note, this way always leads to a subquery, so if key of referenced entity is known, it is strongly recommended to use the 1st way.

Constructing update expressions of the fly

Set extension method can be used in scenarios when the update expression is constructed in runtime, for example:

bool condition = CheckCondition();
var query = Query.All()<Bar>
  .Where(a => a.Id == 1)
  .Set(a => a.Count, 2);

if(condition)
  query = query.Set(a => a.Name, a => a.Name + "test");
query.Update();

Updating lots of properties at once

In a scenario when many properties must be updated at once, the alternative version of update extension syntax might be more convenient to use. The main method is called Update instead of Set and it takes a constructor with object initializer as argument:

Query.All<Bar>()
  .Where(a => a.Id == 1)
  .Update(a => new Bar(null) { Count = 2, Name = a.Name + "test", dozens of other properties... });

Note, while you have to populate the constructor with arguments because compiler requires that, it will never be called, only the object initializer will be processed. So it is safe you set fake arguments to the constructor. In all other ways these 2 kinds of syntax are equal, just choose the one that is convenient for you.

Deleting entities

Delete syntax is pretty straightforward, no new rocket science is here. It is almost the same as Update syntax, but use Delete instead.

Query.All<Foo>()
  .Where(a => a.Id == 1)
  .Delete();

is translated to:

DELETE [dbo].[Foo]
FROM [dbo].[Foo] AS j0 INNER JOIN (
SELECT
  [a].[Id]
FROM
  [dbo].[Foo] [a]
WHERE
  ([a].[Id] = 1)
) AS j1 ON (j0.[Id] = j1.[Id])

Known limitations

1. This version supports Microsoft SQL Server only.
2. When updating a reference field, you can't refer to the entity that is being updated, for instance:

Query.All<Foo>()
  .Where(a => a.Id == 1)
  .Set(a => a.Bar, a => Query.All<Bar>().FirstOrDefault(b => b.Name == a.Name))
  .Update();

3. Session.SaveChanges() method is executed before any batch server-side operation. This might lead to validation of entities, depending on validation configuration.
4. Every batch server-side operation cleans Session cache to provide data consistency.
5. Batch server-side operations don't support compiled LINQ queries.

Credits

All credits go to Alexander Ovchinnikov. The extension is a must-have, I'm absolutely sure that it will be very popular among DataObjects.Net community.

Thanks, Alexander!

P.S.
The second part is coming soon. Stay tuned.

Precise control over indexes

2011-11-18T16:12:00.000+06:00

This is a detailed description of the index-related features from the upcoming release mentioned in the previous post.

Database indexes were invented to improve the speed of data retrieval operations on a database table. But as always, they have the cost: slower writes and increased storage space. So database architects have to keep the balance between faster data retrieval and slower writes. Ideally, indexes should be applied only on columns that are used in filtering, ordering, etc.

1. Control over indexes on reference fields

Versions of DataObjects.Net prior to the upcoming one were pretty straightforward and applied indexes on every reference property, for example, in this model index would be placed on Owner property automatically.

public class Penguin : Entity {

  [Field]
  public Person Owner { get; set; }
}

DataObjects.Net behaved so in assumption that such indexes would boost performance in queries like:

var PoppersPenguins = session.Query.All<Penguin>().Where(a => a.Owner == MrPopper);

But what if the application doesn't have such queries? And the index that is created and maintained by the database is absolutely useless, moreover, it makes the performance worse? The upcoming version of DataObjects.Net has the answers. Here is what you can do to prevent automatic index creation on a reference field:

public class Penguin : Entity {

  [Field(Indexed = false)]
  public Person Owner { get; set; }
}

2. Control over index clustering

There are 2 main approaches in physical organization of data tables: unordered and ordered. The first one means that the records are stored in the order they are inserted, the second implies that the records are pre-sorted before storing. Both of them have advantages and disadvantages, depending on structure of primary key, usage scenarios, etc. Some database servers supports both cases, others - only one. Microsoft SQL Server supports both: unordered approach is a "heap table (file)" and ordered one is based on "clustered index" when data rows are physically sorted according to position of primary key in internal index structures (B+ tree).

For Microsoft SQL Server DataObjects.Net always chose "clustered index" as an organization of physical storage because this is quite efficient in most cases with only few exceptions: when your primary key is not integer auto-incremented data type but uniqueidentifier or char/varchar, clustered indexes become less efficient on data inserts. Until now there was no way to say that there is no necessity to make primary index clustered, but that has changed: DataObjects.Net provides easy way to control clustering of indexes. Here is how:

// Penguin table should not be clustered
[HierarchyRoot(Clustered = false)]
public class Penguin : Entity {

  [Field]
  public Person Owner { get; set; }
}

Note, removing clustering from hierarchy root you remove it for all its descendants.

Additional feature is the ability to define an index that is not primary and then use it for clustering, like this:

// Person table should be clustered by Name column
[HierarchyRoot]
[Index("Name", Clustered = true)]
public class Person : Entity {

  [Field]
  public string Name { get; set; }
}

This can be done for each class separately except the case when SingleTable inheritance scheme is used. Another obvious restriction is that there can be only one clustered index per table.

3. Support for partial (filtered) indexes

A partial index, also known as filtered index is an index which has some condition applied to it so that it includes a subset of rows in the table. This allows the index to remain small, even though the table may be rather large, and have extreme selectivity.

Our goal was not only to add the support, but to make it easy to use and prevent users from the necessity to write database server-dependent expressions in index definitions. Therefore, we decided to implement the following technique that gives us compile-time validation, type-safety and the power of standard .NET expressions:

[HierarchyRoot
[Index("Owner", Filter = "OwnerIndex")]
public class Penguin : Entity {

    public static Expression<Func<Penguin, bool>> OwnerIndex()
    {
      return p => p.Owner != null;
    }

    [Field]
    public Person Owner { get; set; } 
}

Note that depending on inheritance scheme applied, partial indexes can or can't contain expressions with columns defined in ancestors/descendants.

In case you want to move filter expression to a separate class, you should use the following construct:

[HierarchyRoot]
[Index("Owner", Filter = "PenguinOwnerIndex", FilterType = typeof(FilterExpressions))]
public class Penguin : Entity {

    [Field]
    public Person Owner { get; set; } 
}

public static class FilterExpressions {

    public static Expression<Func<Penguin, bool>> PenguinOwnerIndex()
    {
      return p => p.Owner != null;
    }
}

Partial indexes are supported in Microsoft SQL Server and PostgreSQL providers.

In the next post I'll describe other features of the upcoming release, stay tuned. In the meantime, we are preparing the new builds, installers and stuff.

Upcoming major update

2011-11-14T20:08:00.000+06:00

Hello everybody,

Despite the fact that there was no news in this blog from DataObjects.Net team for a couple of months, this doesn't mean that we were having rest or watching endless TV-series. We've been fixing bugs and inventing some really cool features for our customers. Let's take a closer look at the details.

First of all, bugs fixed:

JoinedTuple WCF deserialization is fixed. This might appear only in cases when Entity has more than 63 persistent properties
Key.Equals & TypeReference.Accuracy were fixed
Type descendants & interface implementors discovery in IndexBuilder is fixed
Project template generated wrong Assembly name for projects with spaces in project name.
HintGenerator throwed NullReferenceException on GenerateCleanupByForeignKeyHints method
Foreign keys were missed in some complex scenarios
Wrong linq translation of IN clause with empty list is fixed
Wrong linq translation of Nullable boolean fields is fixed
It wasn't possible to delete and create entity with same key (within active inconsistency region).
Primary key alteration no more leads to table recreation
Usage of Prefetch no more leads to possible memory leaks
Bug with translation of Contains method

Updates to the existing functionality:

SchemaComparisonResult is included into SchemaSynchonizationException for simplificationf of upgrade procedure writing and debugging
StorageException now contains additional information about database, table, column, value and violated constraint
Guid values can be used as TypeDiscriminator values
The order of upgrade sequence is changed so unique constraints and foreign keys are removed at the very beginning of the upgrade procedure and are applied only after custom upgrade handlers finish their work

The most interesting part, features:

Basic support for SqlGeometry & SqlGeography types, spatial index support in SQL Server driver.
Precise control over reference properties indexing
Partial (filtered) indexes based on lambda syntax
Сontrol over primary and regular index clustering
Creating and registering LINQ extensions made more user-friendly
Attributes overriding

Simply put, the features are so dramatic that we are releasing the stuff as a major version update. DataObjects.Net 4.3.7 branch will become 4.3.8 and 4.4.0 will be known as 4.4.1 (one of our lead developers call this update as DataObjects.Net R2 and I understand him pretty much).

While the above mentioned changes are being thoroughly tested under various environments and being prepared for the release, we'll describe the features listed above in a dedicated series of posts.

Thank you! Stay tuned.

Update of licensing component in DataObjects.Net 4.5 Beta 4

2011-08-17T15:19:00.002+06:00

As you might remember, a year ago DataObjects.Net changed its license and become proprietary. In order to protect the product from being stolen we decided to use Eziriz .NET Reactor library, which fitted rather well to DataObjects.Net distribution model (trial mode → purchase → simple activation via internet). And it seemed smooth and efficient until one nuisance was discovered.

.NET Reactor operates with so-called Hardware Id (HWID) which can be calculated from identifiers of four hardware components: processor, motherboard, network card & hard disk drive. We had decided to choose the first three and unfortunately that was rather short-sighted decision because (it was found out later), .NET Reactor takes into account all network cards, even virtual, so when a DataObjects.Net customer plugged-in his mobile phone or opened a VPN connection, a new network interface appeared, HWID changed and therefore, valid DataObjects.Net license suddenly became invalid.

To sort out the problem we are changing the implementation of licensing scheme in DataObjects.Net 4.5 - network cards identifiers will be taken into account no more. As a result of the algorithm alteration, HWID will change and this will require 2 simple actions: revoking previous HWID license and activating the new one. We understand that this might be a noticeable inconvenience, that's why the measure is applied only to the upcoming version while DataObjects.Net 4.4 stays untouched.

For users of DataObjects.Net 4.4 who regularly face with HWID changes, I recommend the following path:

make a backup of your %DataObjects.Net directory%
download DataObjects.Net 4.5 Beta 4
take Xtensive.LicenseManager.dll & Xtensive.Aspects.Weaver.dll from there and replace the corresponding files in %DataObjects.Net directory%\Bin\Latest, %DataObjects.Net directory%\Bin\Debug & %DataObjects.Net directory%\Bin\Release folders.

Here is how the process of hardware license update looks like:
1. When using the licensing component from DataObjects.Net 4.5 you might see the following screen:

Note that License Manager will show you the new HWID, which is calculated without data about network cards. This HWID is not yet activated. If you have Ultimate license, go directly to the step 4.

2. Open Explorer and point it to C:\ProgramData\DataObjects.Net folder. Usually this folder stores primary (or company) license (DataObjects.Net.license file) and the hardware one (XXXX-XXXX-XXXX-XXXX-XXXX.hwl file).

Here "3CA3-0442-7A86-4820-423A.hwl" is the file with my previous hardware license. So open your browser and go to My Subscriptions to revoke the old hardware license.

3. Revoke the outdated hardware license. As you have upgraded to DataObjects.Net 4.5, you wouldn't need the hardware license from the previous version.

4. In License Manager click "Install License...".

Note that primary (company) license is still valid and doesn't require any changes. Choose "Hardware key activation: Internet" and voilà, activation is successful.

DataObjects.Net 4.5 Beta 4 is available for download on the website.

DataObjects.Net 4.3 & 4.4 are updated to the latest revision

2011-07-31T21:01:00.000+06:00

Today both stable versions of DataObjects.Net are updated to the revision 7685. This build includes the extension of Upgrade mechanism that was described in the previous post as well as the following changes:

FieldAttribute.DefaultValue now works with all supported primitive types including Enums and Guids
Domain model builder detects columns with names that differ only in letter case
Overloads for upgrade hints constructors are added
SessionExtensions.Remove for SessionOptions.ServerProfile is fixed
TypeInfoCollection.FindInterfaces, FindImplementors, FindDescendants methods are fixed
Explicit interface implementation analysis in ModelInspector is updated

Persistent field discovery through indexer is fixed in LINQ

// MyEntity.MyField can be non-public now
session.Query.All<MyEntity>.Where(e => e["MyField"] == value);

Persistent.AdjustValue methods are added. This is useful in cases when you need an extension point to do some actions with field value after it is read from storage but not yet returned to the caller and vice versa.

public class MyEntity : Entity {

  // This is called on GetFieldValue
  protected override object AdjustFieldValue(FieldInfo field, object value)
  {
    if (field.Name != "MyField")
      return value;

    // Do some actions with value
    return value;
  }

  // This is called on SetFieldValue
  protected override object AdjustFieldValue(FieldInfo field, object oldValue, object newValue)
  {
    if (field.Name != "MyField")
      return value;

    // Do some actions with value before it is stored
    return value;
  }

The updated installers as well as binaries can be downloaded from the official website: dataobjects.net.

More flexibility to database schema upgrade

2011-07-16T21:12:00.000+06:00

In this post I'm going to describe one of the most advanced and appreciated features of DataObjects.Net — automatic database schema upgrade.

You know, automatic database schema generation for Code-First & Model-First ORMs is a vital requirement, however while the task is not trivial by itself, it is not so difficult in comparison with continuous domain model & database schema synchronization. One can imagine all kind of operations on domain model: creating, renaming, moving, splitting, merging, deleting types, fields, associations, field options, index options, validation constraints, etc. All these types of changes must be propagated by ORM to database schema more or less transparently and without any possible loss of data.

In DataObjects.Net this goal is achieved with the help of mature upgrading framework that had been polished for years in version 3.x branch (starting from 2003 year) and then was migrated to version 4.x one with numerous core updates and extensions.

This could be surprising, but the core component of the upgrade framework is not translation of upgrade actions to SQL or making changes to a database schema, but the effective comparison of 2 abstract models. I'm talking about Xtensive.Modelling that was invented for describing and comparing models of any thing. In case of DataObjects.Net it is being used to compare 2 models of a storage.

Here is how the whole process is constructed. We build domain model and convert it to a unified model of storage. In parallel, we extracting metadata about database schema and converting it to the model of existing storage. After that we compare these two and additionally pass to the comparison procedure a set of upgrade hints that are provided by a user. As a result, we get a difference between 2 models and a sequence of upgrade actions that must be executed in order to convert the existing storage to the new one.

Upgrade actions are taken place only when a domain is being built in DomainUpgradeMode.Perform or PerformSafely. These two have one principal distinction: while Perform silently alters whatever is required even with data loss, PerformSafely guarantees that nothing will be removed unless is explicitly declared by a user by using special upgrade hints and attributes. The hints are nonetheless important and useful in both scenarios as they provide additional information for the comparison routine on what changes are made to domain model.

What are these hints?

RenameTypeHint — for renaming a persistent type
RenameFieldHint — for renaming a persisting field
RemoveTypeHint — for removing a persistent type
RemoveFieldHint — for removing a persistent field
ChangeFieldTypeHint — for a situation when type of a persistent field is changed
MoveFieldHint — for moving a persistent field from one type to another
CopyFieldHint — for copying a persistent field from one type to another

The hints mechanism is intended to be used in custom implementation of UpgradeHandler class. This can be included into an assembly that is going to be upgraded from version "1.0.0.0" to another one and can look like this:

public class MyUpgradeHandler : UpgradeHandler
{
  public override bool CanUpgradeFrom(string oldVersion)
  {
    return oldVersion == "1.0.0.0";
  }

  protected override void AddUpgradeHints()
  {
    var hintSet = UpgradeContext.Hints;
 
    hintSet.Add(
      new RenameTypeHint("MyProduct.Model.Customer", typeof (Person)));
    hintSet.Add(
      new RenameFieldHint(typeof (Person), "Name", "FullName"));
  }
}

More about the hints and usage examples in our manual.

The upgrade hints infrastructure serves well for the overwhelming majority of scenarios but there are relatively rare situations where a change in domain model can't be described with these hints. We were gathering information and analyzing such cases and afterall, decided to extend the interface of UpgradeHandler class to provide an additional point where the upgrade routine can be corrected by user. On the picture above there is the last point, where upgrade actions are generated based on the storage models comparison result. Until now, these actions were automatically applied to a database schema and there was no way to control this process.

We are adding a method to UpgradeHandler class that exposes a sequence of upgrade actions before thay are applied to database scheme:

public class UpgradeHandler : IUpgradeHandler

    // ...

    public virtual void OnBeforeExecuteActions(UpgradeActionSequence actions)
    {
      // In overridden method actions can be added, edited, removed, etc.
    }
}

UpgradeActionSequence contains all actions that will be played against a database scheme, split in groups. An action is a regular SQL command. In this method any action can be removed, edited, moved from one group to another, new actions can be added to the sequence and so on.

The actions are executed in the following order:

01. NonTransactionalEpilogueCommands
02. Open transaction
03. CleanupDataCommands
04. PreUpgradeCommands
05. UpgradeCommands
06. CopyDataCommands
07. PostCopyDataCommands
08. CleanupCommands
09. Commit transaction
10. NonTransactionalEpilogueCommands

Note the transaction boundaries: all commands except those that don't support transactional execution are run in one transaction so on any error the scheme will stay valid and integral.

The new bits are being tested now and will be available soon as nightly builds. After the thorough testing, the updated DataObjects.Net will be available as usual on our website.

Thanks for your attention.

DataObjects.Net 4.5 Beta 3

2011-06-26T19:07:00.001+06:00

Today DataObjects.Net team is happy to publish the third beta of 4.5 version. This release mostly contains changes in the security system as well as bug fixes merged from the stable branch.

After the Beta 2 was published, we received great feedback concerning the security system and we are very glad for that. Thanks to all of you who dropped us a line concerning this stuff.

Changes from Beta 2

First and the most important one is that roles are made persistent. There were numerous requests for this feature, moreover the idea of Terje Myklebust that he formulated as a templates for roles fits to this pattern very well — a persistent class serves as a template, so you can have as many parameterized instances of it as you need. Here is the updated Role hierarchy:

public interface IRole : IEntity
  {
    [Field]
    string Name { get; }

    [Field]
    [Association(PairTo = "Roles", OnOwnerRemove = OnRemoveAction.Clear, OnTargetRemove = OnRemoveAction.Clear)]
    EntitySet Principals { get; }

    IList Permissions { get; }
  }

  [Index("Name", Unique = true)]
  public abstract class Role : Entity, IRole
  {
    [NotNullConstraint(Mode = ConstrainMode.OnSetValue)]
    [Field(Length = 128)]
    public string Name { get; protected set; }

    [Field]
    public EntitySet Principals { get; private set; }

    public IList Permissions { get; }

    protected void RegisterPermission(Permission permission);

    protected abstract void RegisterPermissions();

    protected Role(Session session)
      : base(session)
    {
      Name = GetType().Name;
    }
  }

Xtensive.Practices.Security contains the abstract class Role that implements all the required infrastructure for permission registration and handling. Each instance of Role must contain unique name. By default, Role class sets name property to name of the concrete type. In case you want more than one instances of a role of the same type, you must give them unique names. Role and Principal now are connected via paired entitysets. So a principal knows all its roles and vice versa.

Note that the Role class doesn't define hierarchy root and key fields. You must do this manually as you do in case of Principal, for example:

[HierarchyRoot(InheritanceSchema = InheritanceSchema.SingleTable)]
  public abstract class EmployeeRole : Role
  {
    [Field, Key]
    public int Id { get; set; }

    protected override void RegisterPermissions()
    {
      // This is base role for every employee

      // All employees can see products
      RegisterPermission(new Permission());
      // All employees can see employees
      RegisterPermission(new Permission());
    }

    protected EmployeeRole(Session session)
      : base(session)
    {
    }
  }

All other roles inherit EmployeeRole. Note that in case of roles the SingleTable inheritance scheme is the best option as all role types are similar and can be effectively placed inside a single table.

Other changes:

Session.ValidatePrincipal method is renamed to Session.Authenticate.
IPrincipalValidationService is renamed to IAuthenticationService
GenericPrincipalValidationService is renamed to GenericAuthenticationService
GenericRoleProvider, PrincipalRole, PrincipalRoleSet, RoleSet are discarded as useless.

Roles as templates

There was a fruitful discussion after the previous post and the idea of role templates was suggested. Here is how it can be implemented in the Beta 3. I'll take the same scenario with branches and office manager roles.

Fisrt, let's define branches

[HierarchyRoot]
  public class Branch : Entity
  {
    [Field, Key]
    public int Id { get; private set; }

    [Field]
    public string Name { get; set; }

    public Branch(Session session)
      : base(session)
    {}
  }

And then, define a branch office manager role

public class BranchOfficeManagerRole : EmployeeRole
  {
    [Field]
    public Branch Branch { get; set; }

    private IQueryable GetCustomers(ImpersonationContext context, QueryEndpoint query)
    {
      return query.All()
        .Where(c => c.Branch == Branch);
    }

    protected override void RegisterPermissions()
    {
      RegisterPermission(new Permission(true, GetCustomers));
    }

    public BranchOfficeManagerRole(Session session, Branch branch)
      : base(session)
    {
      Branch = branch;
      Name = branch.Name + "OfficeManager";
    }
  }

See, the role class is not tied to a concrete branch office instance, it only declares a connection between a role type and a branch type instead. The concrete Branch instance is passed in the constructor. Also note how Name property is formed in the constructor to avoid non-uniqueness.

Having these classes declared we can easily use them in creating the appropriate role instances as many as we need. Moreover, we can create branches and branch-dependent roles in runtime.

// Branches
var southBranch = new Branch(session) { Name = "South"};
var northBranch = new Branch(session) { Name = "North"};

// Roles
var southBranchOfficeManagerRole =  new BranchOfficeManagerRole(session, southBranch);
var northBranchOfficeManagerRole =  new BranchOfficeManagerRole(session, northBranch);

// Employees
var user1 = new Employee(session);
user1.Roles.Add(southBranchOfficeManagerRole);

var user2 = new Employee(session);
user2.Roles.Add(northBranchOfficeManagerRole);

// By adding both roles to an employee we can give him a superset of permissions
var user3 = new Employee(session);
user3.Roles.Add(southBranchOfficeManagerRole);
user3.Roles.Add(northBranchOfficeManagerRole);

Download

DataObjects.Net 4.5 Beta 3 can be downloaded from the website.

P.S.
Dear DataObjects.Net users and contributors. The Beta 3 is very close to the Release Candidate. But before the main branch is frozen, I want to clarify
a question: should permissions be persistent or not? Is it vital? If yes, how filter expressions should be stored?

If the question is given a sensible answer, we'll continue implementing persistent permissions and make Beta 4; otherwise we will proceed to RC 1.

Thank you.

P.P.S.
Dear Malisa Ncube,
It seems that after these alterations you'll have to update the SalesPoint database creation script for MySQL. Sorry for that, hope this won't tale too much time.

DataObjects.Net on Twitter

2011-06-22T21:02:00.001+06:00

Hello everybody,

Finally DataObjects.Net reached Twitter. =)
Follow us for the latest news and updates.

Follow @DataObjectsNet

SalesPoint sample database for MySQL

2011-06-15T20:09:00.000+06:00

This is an addition to the previous post, for those who prefer using MySQL instead of Microsoft SQL Server. Malisa Ncube made a conversion of salespoint.sql file from DataObjects.Net 4.5 Beta 2 package to MySQL syntax and very generously published in his blog.

You will also find there some moving impressions about the SalesPoint sample running on MySQL because he is the official 'father' of MySQL driver for DataObjects.Net.

Thanks, Malisa!

DataObjects.Net 4.5 Beta 2

2011-06-13T21:37:00.001+06:00

Today the DataObjects.Net Team is releasing the second beta of the upcoming 4.5 version of DataObjects.Net. The beta is mostly dedicated to the security system.

All security-related classes are located in a separate assembly called Xtensive.Practices.Security. Let's explore what types to be aware of the assembly includes:

IPrincipal, Principal & GenericPrincipal
Role & RoleSet
Permission & PermissionSet
IHashingService with several implementations
IPrincipalValidationService with a generic implementation
ImpersonationContext
some Session extension methods

Most of them have been already discussed in the previous posts on the topic. However, let's recall the main principals & usage scenarios on a security sample called SalesPoint.

Adding the security system to your project
1. Add reference to Xtensive.Practices.Security assembly

2. Register types from Xtensive.Practices.Security in your domain.

<domain connectionurl="sqlserver://./SalesPoint"upgrademode="Skip">
    <types>
        <add assembly="SalesPoint">
        <add assembly="Xtensive.Practices.Security">
    </types>
</domain>

Xtensive.Practices.Security contains the following persistent types: Principal, GenericPrincipal (both are abstract) and PrincipalRole which is used for storing role names for a principal.

3. Make your own persistent type that describe a user of your application. Inherit it from Principal or GenericPrincipal classes.

Principal class defines the minimum IPrincipal implementation and can be used for all kind of users, no matter whether you use login/password authorization scheme, Windows-based one or your own.

GenericPrincipal class is specifically designed for login/password authorization scheme. It already contains all the required properties and methods for storing password hash, for setting password, etc. Moreover, generic principal validation service is oriented only on GenericPrincipal class and its inheritors. So, in the overwhelming majority of scenarios you should inherit from GenericPrincipal class.

In the sample the login/password authorization scheme is used, so the Employee class is inherited from the GenericPrincipal one. Note that you have total control on properties of user hierarchy: you define the hierarchy inheritance scheme as well as the structure of Key fields.

[HierarchyRoot]
public class Employee : GenericPrincipal
{
  [Field, Key]
  public int Id { get; private set; }

  // Other fields
}

More about principal types: part 5.

4. Define which hashing algorithm will be used. In this version md5, sha1, sha256, sha384, sha512 hashing algorithms are provided plus plain one that allows to store passwords as is, without hashing. This might be useful for testing purposes but it is strongly recommended to use true hashing one in the real life applications. In the sample the plain one is used, here is how it can be configured:

<configSections>
    <section name="Xtensive.Security" type="Xtensive.Practices.Security.Configuration.ConfigurationSection, Xtensive.Practices.Security" />
  </configSections>

  <Xtensive.Security>
    <hashingService name="plain"/>
  </Xtensive.Security>

If no hashing service is set, then the system will fall back to the 'plain' one.

Managing passwords and validating users

Having the above-mentioned steps done, you are getting the ability to manage users, set their passwords and validate them. Here is how:

using (var session = domain.OpenSession()) {
  using (var trx = session.OpenTransaction()) {

    var employee = new Employee(session);
    employee.Name = "Steve Ballmer";
    employee.SetPassword("developers, developers, developers, developers");
    trx.Complete();
  }
}

using (var session = domain.OpenSession()) {
  using (var trx = session.OpenTransaction()) {

    var employee = session.ValidatePrincipal("Steve Ballmer", "developers, developers, developers, developers");
    Assert.IsNotNull(employee);
    trx.Complete();
  }
}

Defining roles

Whereas user management is the essential part of any security system, roles sometimes are used as an optional addition, thus loosing all their power. But it's you who decide whether to employ them or not. In Xtensive.Practices.Security roles are optional too.
Roles are ordinary classes, not persistent ones, and so are permissions. In order to utilize the roles mechanism you inherit from base Role<T> class and declare permissions for domain model types, like here:

public class EmployeeRole : Role
{
  public EmployeeRole()
  {
    // This is base role for every employee.
    // It defines read-only access to products and employees for all staff.

    // All employees can see products
    RegisterPermission(new Permission<Product>());
    // All employees can see employees
    RegisterPermission(new Permission<Employee>());
  }
}

public class StockManagerRole : EmployeeRole
{
  public StockManagerRole()
  {
    // Stock manager inherits all permissions from Employee role
    // In addition, it declares write access to products

    // Stock managers can see and edit products
    RegisterPermission(new Permission<Product>(canWrite:true));
  }
}

Here is more advanced role declaration. You can declare secure queries for persistent types and use you own permission classes as well:

public class SalesRepresentativeRole : EmployeeRole
{
  private static IQueryable<Order> GetOrdersQuery(ImpersonationContext context, QueryEndpoint query)
  {
    // Sales representative role has access to its own orders only
    return query.All<Order>()
      .Where(o => o.Employee == context.Principal);
  }

  public SalesRepresentativeRole()
  {
    // Sales representative inherits Employee permissions

    // Sales representative can see and edit customers
    RegisterPermission(new Permission<Customer>(canWrite:true));
    // Sales representative can see and edit sale orders but not approve
    RegisterPermission(new OrderPermission(canWrite:true, canApprove:false, GetOrdersQuery));
  }
}

Important: for the ease of use give your roles parameterless constructors. If this is unacceptable, then you should provide to a framework a list of role instances. I'll describe this this later.

More about roles and permissions: part 2, part 3, part 4.

Impersonation

The next question after we've successfully defined users, authentication scheme, roles and permissions is "How the hell will these parts work together?". Let's see.

You already know how to validate user by the pair of name and password.

If the validation is successful, you may impersonate current Session with user's account. After this is done, the security framework will provide you with all necessary infrastructure on what permission the user has, which roles he is in.

using (var session = domain.OpenSession()) {
  using (var trx = session.OpenTransaction()) {

    var employee = session.ValidatePrincipal("Steve Ballmer", "developers, developers, developers, developers");

    // Opening an impersonation context
    var context = session.Impersonate(employee);

    // Checking permissions
    context.Permissions.Contains<Permission<Customer>>(p => p.CanRead);
    context.Permissions.Contains<OrderPermission>(p => p.CanApprove);

    // Closing the context
    context.Undo();

    trx.Complete();
  }
}

Here is how permissions are used to restrict screens of the sample application:

Note that currently logged in employee is in StockManager role that prohibits access to Customers and Orders. The main menu just checks whether current impersonation context contains the appropriate permission and acts accordingly by enabling or disabling controls.

Probably, the most exciting and important feature of the framework is automatic application of secure filters to every query that is being executed through Session.Query endpoint.

For example, if we log in with an employee who is in SalesRepresentative role, which restricts all orders to his own orders only, we will see the following picture:

We logged in as a Robert King, a sales representative. He can see only his own orders as the filter is declared in SalesRepresentative role and is applied automatically. The application doesn't know about users, permissions, roles, etc. All this stuff is provided by Xtensive.Practices.Security layer. Note that Customers and Orders views are available to him, but the "Approve" button is not, because the role doesn't declare access to "Approve" action.

What will happen if we log in as SalesManager? Let's see:

The user also has access to Customers and Orders as SalesManager role inherits it from SalesRepresentative one. Moreover, the role doesn't have such restriction for Orders, the employee see not only his own orders but the orders of employees from his department. In addition, the button "Approve" is enabled.

More on applying security filters to queries: part 6

A few notes about the impersonation context
ImpersonationContext class implements IDisposable, so you can employ using pattern. The context also supports nesting.
Current impersonation context instance can be accessed through Session, so you don't have to pass the reference to the context everywhere you might need it.

var context = session.GetImpersonationContext();

How to build the SalesPoint sample application
SQL script that builds the required "SalesPoint" database is included into the solution "Samples" and is located in the root folder of the SalesPoint project. Run the script against your database server and check that the database is successfully created. After that update the connectionUrl in app.config file according to the
path of your database server.

Download

DataObjects.Net 4.5 Beta 2 can be downloaded from the website.

P.S.
Dear users of DataObjects.Net!
This is DataObjects.Net Beta 2, so I'm asking for your feedback. Play with the sample or try creating your own one, try applying the security framework to your real projects, do anything you want with it including the most weird scenarios (I know you can), I'll be happy to receive any comment no matter good or bad from you. Any of these will definitely help to make the product better and keep our requirements for high quality product.

Thank you.

Report about Uganda .NET Usergroup

2011-06-08T21:38:00.000+06:00

Malisa Ncube has written a nice post about the event that took place on Friday, 27th May 2011. Malisa presented DataObjects.Net on the meeting and demonstrated how DataObjects.Net fits into Microsoft technology stack.

Don't miss the downloadable presentation. The link is located in the end of his report. Really nice one!

DataObjects.Net Entity Designer update

2011-06-07T21:33:00.000+06:00

Talented Peter Šulek announced the major update of the Entity Designer project.

The update includes list of bug fixes along with the new important features like POCO/DTO generation support, optional DataContract and DataMember attributes generation, redesigned "Add association" dialog and much more.

Redesigned Association dialog

Read complete announcement in Peter's blog.

So, grab the bits and start playing with the tool. Any feedback is highly appreciated. The sooner the designer is tested in various scenarios, the sooner it will be released in production. So, DataObjects.Net community members, participate! Help making the tool perfect.

On security system, part 6

2011-06-04T20:16:00.001+06:00

It seems that in the end of the previous post I was a bit wrong. One more topic left for detailed discussion. And its name is "Query conflicts resolving".

Let me explain it a bit. Say, there is a consulting firm that is managed by 2 managers. First of them, Dan, is responsible for negotiations with automobile companies, while the second one, John, works with aircraft enterprises. According to the approach that is described in the previous set of posts the security domain model would contains of two roles: AutomobileManagerRole and AircraftManagerRole, each of them would include a correspondent restrictive query.

public class AutomobileManagerRole : Role
  {
    private static IQueryable<Customer> GetCustomers(ImpersonationContext context, QueryEndpoint query)
    {
      return query.All<Customer>()
        .Where(c => c.IsAutomobileIndustry);
    }

    public AutomobileManagerRole()
    {
      RegisterPermission(new CustomerPermission(true, GetCustomers));
    }
  }

  public class AircraftManagerRole : Role
  {
    private static IQueryable<Customer> GetCustomers(ImpersonationContext context, QueryEndpoint query)
    {
      return query.All<Customer>()
        .Where(c => c.IsAircraftIndustry);
    }

    public AircraftManagerRole()
    {
      RegisterPermission(new CustomerPermission(true, GetCustomers));
    }
  }

Dan would be associated with AutomobileManagerRole and John - with AircraftManagerRole. The roles effectively avoid both of them to see customers that belong to industry other than a manager is responsible for.

But imagine a situation when one of the managers, let it be Dan, left on a vacation. To continue automobile customers management process John should get access to customers of Dan for the vacation period. To achieve this, a system security administrator goes to a security administration console and temporarily adds AutomobileManagerRole to John's account. As a result, John's account starts containing 2 roles, both of them with restrictive query for customers.

So, what should happen when John will execute a query for customers? How the conflict between 2 restrictive queries should be resolved?

The answer is that if the first role grants access to X set of entities and the second role grants it to Y set of entities then the result of combination of these roles should be a union of X and Y, not intersect or except.

Applying this approach to the situation with the managers, John will get access to the result of the following query:

query.All<Customer>()
  .Where(c => c.IsAutomobileIndustry)
  .Union(query.All<Customer>()
        .Where(c => c.IsAircraftIndustry));

This approach will be used always when impersonation context is active and user account contains more then one role with a restrictive query for a querying persistent type.

On security system, part 5

2011-05-27T19:34:00.000+06:00

After releasing DataObjects.Net 4.5 Beta 1 with Firebird & MySQL providers as well as with LINQPad provider, the team switched back to the security-related stuff.

In the previous part we discussed the roles and permissions in terms of restricting LINQ queries. This time let's focus on users, passwords and validation.

First of all, according to the requirements to the security system listed in the very first post concerning this topic, we announced that it would be good if we integrate somehow with the core .NET security interfaces, like IPrincipal & IIdentity. As a result, our core IPrincipal interface inherits System.Security.IPrincipal interface and adds 2 persistent fields and 1 method:

public interface IPrincipal : IEntity, System.Security.Principal.IPrincipal
  {
    [Field]
    string Name { get; }

    [Field]
    [Association(PairTo = "Principal", OnOwnerRemove = OnRemoveAction.Cascade)]
    PrincipalRoleSet PrincipalRoles { get; }

    bool IsInRole(Role role);
  }

Field 'Name' is used for storing identity information in storage. 'PrincipalRoles' is a set of roles that a principal owns. The PrincipalRole type is just a auxiliary type that help associate a Principal with its roles. A role itself is not persistent type, so we use its name as a reference.

  [HierarchyRoot]
  [KeyGenerator(KeyGeneratorKind.None)]
  public class PrincipalRole : Entity
  {
    [Field, Key(0)]
    public IPrincipal Principal { get; private set; }

    [Field(Length = 50), Key(1)]
    public string Name { get; private set; }

    public PrincipalRole (Session session, IPrincipal principal, string name)
      : base(session, principal, name) {}
  }

In order not to realize all functionality of IPrincipal interface by yourselves, there is 2 base implementations: Principal & GenericPrincipal. The first one is pure implementation of the IPrincipal interface with no additional stuff. Here it is:

public abstract class Principal : Entity, IPrincipal
  {
    [NotNullConstraint(Mode = ConstrainMode.OnValidate)]
    [Field(Length = 50, Indexed = true)]
    public string Name { get; set; }

    public virtual IIdentity Identity
    {
      get { return new GenericIdentity(Name); }
    }

    [Field]
    public PrincipalRoleSet PrincipalRoles { get; private set; }

    public bool IsInRole(string role)
    {
      return PrincipalRoles.Any(r => r.Name == role);
    }

    public bool IsInRole(Role role)
    {
      return PrincipalRoles.Contains(role);
    }
  }

The second persistent class called GenericPrincipal is designed for use in scenarios with username/password matching:

public abstract class GenericPrincipal : Principal
  {
    [Field(Length = 50)]
    public string Password { get; protected set; }

    public virtual void SetPassword(string password);
  }

Note that both classes neither define Key fields nor apply HierarchyRoot attribute because no prediction can be made about such properties in your domain models. However, this means that you should add your own persistent type called User or similar and inherit from Principal or GenericPrinipal types in order to use all features of the security system. No additional coding is required, just inherit one of them, define Key field(s) and apply HierarchyRoot on top and that's all.

As GenericPrincipal type is intended to be used in username/password scenarios, the next question is: who will be responsible for possible encryption of passwords and how users will be validated/authenticated?

The previous version of DataObjects.Net provided several password encryption algorithms you could choose from, however the possibility to implement your own one was absent. This time we are going to provide a generic interface for string encryption as well as several common implementations. Customers will have the ability to make their own implementations and plug them in. Here is the interface:

  public interface IEncryptionService : IDomainService
  {
    string Encrypt(string value);
  }

It is absolutely simple and straightforward. For now there are 2 realizations: PlainEncryptionService that actually doesn't make any encryption at all and could be used for testing purposes, and Md5EncryptionService. I'll show how to configure the services later.

The next part is user authentication. Keeping in mind that DataObjects.Net-based applications might operate with various types of principals, for example, Windows principal or generic one with username/password authorization scheme, we provide the following generic interface for this task:

  public interface IPrincipalValidationService : ISessionService
  {
    IPrincipal Validate(IIdentity identity, params object[] args);

    IPrincipal Validate(string name, params object[] args);
  }

The method that takes IIdentity as the first parameter is more generic, it might take WindowsIdentity as well as any other IIdentity descendants. The second argument is an array of values that are used for authentication, these could be passwords, tokens, tickets, you name it. The framework will provide base user validation service for username/password authentication scheme, and you'll have the ability to make your own ones.

It seems that there is nothing left to describe. In the next part we'll try making our first sample with integrated security. Stay tuned.

DataObjects.Net on Uganda .NET Usergroup

2011-05-24T20:43:00.000+06:00

Hello All,

On Friday, 27th May 2011 Malisa Ncube will present DataObjects.Net on Uganda .NET Usergroup meeting and demonstrate how DataObjects.Net fits into Microsoft technology stack and how software engineers can accelerate project development using the application framework.

It is a completely free event. If you’d like to attend, please register here.

DataObjects.Net 4.5 Beta 1

2011-05-18T14:55:00.000+06:00

Today the DataObjects.Net Team is releasing the first beta of the upcoming 4.5 version of DataObjects.Net.

In this release are included both new providers: for Firebird 2.x & for MySQL 5.x as well as the LINQPad provider.

Both stable versions are also updated to the latest revision. Issues resolved:

- Index attribute on abstract class not in hierarchy root
- No Foreign Key on field from Interface
- Bug of Inheritance with non open generic
- Unsufficient error message when domain build
- Structure field migration

The beta as well as stable versions are available in the download section of the official website.

Please, report any issues concerning new providers so we could fix them before the final version is released. Thanks.