Morts Like Us

Playing with Ravens

noreply@blogger.com (Anonymous) — Tue, 07 Aug 2012 20:43:00 +0000

Right now, I have a few ideas for pet projects I plan to work on over the next months. More on that in another post, but most of them include a data store other than an RDBMS.

Being on .Net, I have chosen to use RavenDB. Now it’s not that easy for an old SQL boy like me, so I started playing with it and making some notes here.

Getting the software

Ayende said on the mailing list, the current unstable version will be ready in a few month. Realistically, I won’t finish my project before this upcoming version will be out of support , so I can go for unstable confidently. Even more when I read the standard reply on the list for bug reports: "Test will pass in the next build."

Installing

Simple: Unzip build to directory, and call start.cmd. This will even work by clicking on it since a new window pops up by default. However will be a UAC popup as the server calls netsh to grant rights for http.sys, but it requests this only once.

First steps

In the beginning, there was nothing. Not even a database, so let’s create a sample database. Did I mention I love it when batteries are included?

After creating the sample data, let’s take a look at the contents:

Ok, so we can view and inspect and update entities. Now, can we also do queries?

Querying data

Now where are the queries? It turns out (with a little bit of clicking around) that they are filed under indexes.

So let’s start with a dynamic query, which is the equivalent to ad-hoc SQL queries on an RDBMS. Raven uses Lucene query syntax, which is documented on the Lucene tutorial. Now let’s look what albums are of my taste here:

Ok, that’s cool. We have everything we need on the page: Query, results, statistics. However, the result data displayed is not what I wanted. So I hit “Show fields”, hoping to get some dialog for choosing fields. But when I have it activated, Raven only displays the IDs of the documents.

Well, you can change it by right clicking the column titles:

Ok, so we can query the data ad-hoc without writing a map-reduce-function.

Indexes

Back on the index page, the query I just executed is displayed as an temporary index:

Ok, let’s edit this, so we can get the same result as before:

Looks like C# Linq, so how about this:

That looks promising and the index can actually be queried, but the studio shows the same strange result as above:

Eventually I will find that out… some day…

More Indexing

Now let’s go for a more demanding example. I want to know how many albums each Artist has published here. Luckily, there is already an artist index we can start with:

It’s actually quite easy, though I needed some minutes to get it right:

You should keep the following in mind:

Don’t put the Albums count into the group
Use Extension Methods for aggregations
Everything is case sensitive!

Now we nearly got it:

One more thing before I send the ravens back to their nest. I want only Artists that have between 10 and 20 albums published in the database. The default Lucene Syntax could be: Albums: [10 TO 20], but

Lucene searches lexicographically, so we need a special, yet nearly undocumented syntax, that I found in an example in the RavenDB docs:

Conclusion

Now I feel somewhat familiar with the studio, so next time let’s see how we can query this values from within code.

To How Many Bounded Contexts Does Your Model Belong To?

noreply@blogger.com (Anonymous) — Mon, 02 Jan 2012 18:40:00 +0000

Yesterday I have read this blog post by Chad Myers. I agree with him – more or less – on the current state of web frameworks, but I have something to add:

More pants Bras on the head

Chad emphasizes the …Model. Every web framework since WebForms emphasizes the …Model. There is MVC, there is MVVM and MVP. Everywhere there is a …Model. But what is the …Model? Let’s take a closer look.

What is a model?

A model is an abstraction. If I have something complex, something too complex to handle, I create a model that allows me to handle it. Looking at typical web applications, I ask myself: What is so complex here that I need an abstraction layer or even two?

To pull the data from the data store, we use a model. We put bras on the head and chant the rhyme of “Persistence Ignorance”. Then we build another model, now called view model that consists of a projection of the “real model” along with some specialized collections with one or two extra properties, because using more than one object to pass in the view is the deadly sin of web programming.

All this to put a simple SELECT TITLE,AUTHOR FROM POSTS on a web page? You must be kidding.

Complex Applications

Ok, not all applications are tutorial like. Let’s have a look at an application that deserves a model: Imagine something more complex, like Eric Evans shipping sample in Domain Driven Design. Here we have a model and the model will be used to calculate shipping costs and the time required to deliver and so on.

But will you use it in the company’s web application? Most likely not. To be more precise, if you do, you really need to reread Mr. Evan’s book.

So what model will you use in such an application? I guess there will be a CQRS-like denormalized data store for you application and changes are either issued with service calls or commands. In this case you will use your models to put an even simpler SELECT * FROM SpecializedViewTable on a web page.

Something in Between

There are a few web applications that have a model that is the only bounded context and still complex enough to justify a model. If you have such a domain, you’ll be fine with the model cascade on your web application, but I have found them to be quite rare.

The Big Rewrite (1)

noreply@blogger.com (Anonymous) — Thu, 22 Sep 2011 16:26:00 +0000

It has been a long time since my last blog post. It also has been a long time since I worked on the Castle project either. I don’t want to talk about the reasons however, but I had some ideas regarding ActiveRecord which I want to share.
My ideas have nothing to do with the current version of Castle ActiveRecord. Henry has done a great job pushing an RC out of the door, but AR’s codebase has grown over the years into a state that makes it hard to impossible keeping up with NHibernate’s features.
In the meantime, other changes took place in the world of ORMs that make most AR’s current features obsolete:

For NHibernate there are two independent mapping libraries allowing to work without XML. I have used confORM recently and it is a pleasure to use. Mapping with attributes is rather clumsy compared to confORM, FluentNHibernate, or NHibernate’s own mapping by code.
Since NHibernate 2.0 (which is a long time ago), transactions are mandatory. AR uses SessionScope and TransactionScope and a few other scope types which aren’t used widely, making AR even more complicated than naked NHibernate.
NHibernate has new mapping features. Honestly, I don’t know whether someone has added them to the AR codebase. The last time I tried, the visitor model used for examining the attributes drove me nuts.
Entity Framework has matured and while EF 4.1 is still a bit behind NHibernate, it is simpler to use than ActiveRecord.

Goals of ActiveRecord vNext

So what are the features I envision for the next AR version? You might guess them from what I don’t like in the current version:

ActiveRecord API (entity.Save() etc.)
POCO Support
Testability
A single Unit-of-Work concept.
Abstracting from the used ORM as much as ~~possible~~ reasonable.

For now, I will only highlight each of the design goals in short. I will share more on them in separate posts.

ActiveRecord API

AR vNext will concentrate on one major goal: Providing an easy to use API of the active record pattern. As a user, I want to call Save() or Find() from anywhere in my code without passing around session objects, DAOs or repositories.

POCO Support

The model should consist of plain object classes. The current AR requires inheritance for full support of the active record API. AR vNext will not even contain a base class for models. It will not require to use an attribute either. However, there is a drawback: Even with the full power of C# 4.0, implementing an empty interface is needed to streamline the experience.

Testability

Testing without database access is a must for TDD. Even the use of in-memory-databases requires initialization of the ORM which is far more problematic than getting data from an in-process-call to SQLite.
AR vNext will contain the necessary abstractions and native support for mocking and stubbing data access. Have your code use entity.Save() and fail the test if the wrong entity was saved… all without even loading the ORM’s assemblies.

Single Unit-of-Work Concept

A unit of work is mandatory unless you want to code demo apps. However, we don’t need separate concepts for web apps, service executables, GUIs and CLI programs. The single UoW must include transactions and allow both implicit and explicit usage.

Reasonable Abstractions

You might have noticed that I used ORM in the paragraphs above and not NHibernate. Well, while NH will be used and integrated as default ORM in vNext, I strive to abstract it out of the core API, so that it is possible to plug in other persistence frameworks in the future, which might be EF or RavenDB.
This abstraction will not used at any price. Don’t expect to change a configuration value to move from SQL to NoSQL or something similar. The goal is to factor out ORM-specific features in separate classes, so that you can remove the assembly references and have your compiler tell you what is required to adapt in order to use another ORM.

When can I use it?

Right now.
NuGet: Monastry.ActiveRecord-NHibernate
GIT: https://github.com/mzywitza/Monastry.ActiveRecord

Working with XML in PowerShell (2)

noreply@blogger.com (Anonymous) — Thu, 21 Jan 2010 04:05:00 +0000

In a previous post I wrote about examining XML with PowerShell. However, it is often not only necessary to peek into XML, but also to change it.

Updating XML with NAnt

In NAnt, it is possible to use xmlpoke to update XML in arbitrary files. The following NAnt snippet is taking from the build script of ActiveRecord’s test project and allows to adjust the database settings of the build machine.

  <target name="configure-tests">

    <property name="app.config" value="${build.dir}/${project::get-name()}.dll.config" />

    <xmlpoke

      file="${app.config}"

      xpath="/configuration/activerecord/config/add[@key='connection.connection_string']/@value"

      value="${ar.connection.connection_string.1}"

/>

  </target>

In the snippet above I have omitted some 10 more xmlpoke tasks that all change values in the same application configuration file.

How can this be done in PowerShell? The preceding post in this series showed how to assign the output of a command to a variable, so we only have to use a command that reads the contents of a file and assign the output to the variable:

    $app_config = $project_path + "\build\net-3.5\debug\Castle.ActiveRecord.Tests.dll.config"
    [xml] $cfg = Get-Content $app_config

Now we have the XML to update available as an instance of XmlDocument and the full power of .NET at our hands to manipulate it. When we just had to traverse a path to change our XML, we could simply use dotted path. But if we have to differentiate siblings by its attribute values, the dotted path becomes unwieldy as we had to use a for-each-loop. But we can use XPath instead:

    $cfg.SelectSingleNode("/configuration/activerecord/config/add[@key='connection.connection_string']").value = $myDatabaseConnString
    $cfg.SelectSingleNode("/configuration/activerecord/config/add[@key='dialect']").value = $myDatabaseDialect
    # ...

Finally, we have to save the updated XML. There is one caveat here: XmlDocuments don’t keep whitespace but normalize where it is deemed to be safe. But if we change generated files instead of manually edited ones, this is only a minor nuisance.

    $cfg.Save($app_config)

The full script is shown below. As before it is quite short compared to the NAnt XML script.

properties {
    [string] $project_path = "C:\dev\castle\SVN\ActiveRecord"
    $myDatabaseConnString = "PSDBCFG"
    $myDatabaseDialect = "PSDBDIALECT"
}

task default -depends configure_tests

task configure_tests {
    $app_config = $project_path + "\build\net-3.5\debug\Castle.ActiveRecord.Tests.dll.config"
    [xml] $cfg = Get-Content $app_config
    $cfg.SelectSingleNode("/configuration/activerecord/config/add[@key='connection.connection_string']").value = $myDatabaseConnString
    $cfg.SelectSingleNode("/configuration/activerecord/config/add[@key='dialect']").value = $myDatabaseDialect
    # ...
    $cfg.Save($app_config)   
}

Working with XML in PowerShell (1)

noreply@blogger.com (Anonymous) — Wed, 20 Jan 2010 05:56:00 +0000

During the last days, I started reading about PowerShell and PSake. While looking at the NAnt scripts that I currently use, I recognized that among others the capability of examining and editing XML files is required.

Examining XML in NAnt

In NAnt, inspecting XML is done with the xmlpeek-task. It takes a file name, an XPath and a property name to fill with the result.

One of the uses of xmlpeek is to find out the current revision of a code base, for example to set the private part of the version number with it. In the Castle Project’s build script this is done this way:

  <target name="common.find-svninfo">

    <!-- For adding SVN revision to builds -->

    <property name="svn.revision" value="0" overwrite="false" />

    <!-- try to update the revision -->

    <exec

      program="svn"

      commandline='info "${project::get-base-directory()}" --xml'

      output="_revision.xml"

      failonerror="false"/>

    <xmlpeek

      file="_revision.xml"

      xpath="/info/entry/@revision"

      property="svn.revision"

      failonerror="false"/>

    <delete file="_revision.xml" failonerror="false" />

    <echo message="INFO: Using Subversion revision number: ${svn.revision}"/>

  </target>

So while this is quite a clever solution to find out the projects current revision, it has some drawbacks, such as being nearly 20 lines of code and that it uses a temporary file. But it does the job, reading the revision from the project folder.

Examining XML in PowerShell

PowerShell treats XML as a first class type and also has some shortcuts available. If we take a look at the result of svn info, we see that it is thankfully simple:

<?xml version="1.0"?>

<info>

  <entry

     kind="dir"

     path="."

     revision="6536">

...

  </entry>

</info>

And because we can traverse XML nodes and attributes in PowerShell like object properties, it is possible to get the revision number even without an XPath expression.

$revision = $rev_xml.info.entry.revision

So now it is only necessary to fill the $rev_xml variable with the output of the svn info command. The NAnt script does this using a temporary file but PowerShell allows to assign the standard output of a command line program directly to a variable:

$rev_xml = svn.exe info --xml

But PowerShell treats the output of such a program as an array of objects, in this case strings. We have to hint PowerShell that what we want is an XMLDocument instead of an array of strings:

[xml] $rev_xml = svn.exe info --xml

That’s all. We now only have to put this together into a PSake build script for testing and reference.

properties {
    [string] $project_path = "C:\dev\castle\SVN\ActiveRecord"
    $revision = 0
}

task default -depends get_revision
task get_revision {
    [xml] $rev_xml = svn.exe info $project_path --xml 
    $revision = $rev_xml.info.entry.revision
    "INFO: Using Subversion revision number: $revision"
}

This whole script is shorter than the snippet of NAnt script I’ve shown at the beginning. Taking only the relevant work, 5 lines of PS script replace 15 lines of NAnt XML.

The script of course ignores the fact that getting the revision number should not be a task but rather a function that is called by a build task’s precondition for example. I will get back this in a while in another post.

ActiveRecord 2.1 released

noreply@blogger.com (Anonymous) — Thu, 14 Jan 2010 06:05:00 +0000

Yesterday was ActiveRecord 2.1 released. The binaries can be downloaded on SourceForge.

Most of the new functionalities in this release were contributed by Krzysztof Kozmic, a fellow castle committer, who was a great help to get this release out. More thanks go out to the HornGet team, whose efforts took a lot of work out of the release process. Finally, I want to thank all contributors for patches and spotting bugs.

So now what is new in that release?

Updated Dependencies

Castle.Core and Castle.DynamicProxy were updated to their newest releases (1.2 and 2.2 resp.).

NHibernate has been updated to the last stable version 2.1.4 and compiled against the new Castle libraries.

NHibernate.Linq and NHibernate.Search were compiled against NHibernate 2.1.4.

Default configuration feature

This new feature allows to skip all of the <add/>-tags from your configuration if you are only using the database’s default values. In this case your config will be reduced to:

<activerecord>
    <config db="MsSqlServer2005" csn="MyConnectionStringName"/>
</activerecord>

The default configurations are available for most databases.

Inferring PrimaryKeyType from property type

Inspired by FluentNH, ActiveRecord now infers the PrimaryKeyType from the key’s property type:

For Guid PrimaryKeyType.GuidComb is used
For string PrimaryKeyType.Assigned is used
All others default to PrimaryKeyType.Native as before.

Support for backfield and readonly properties

These property accessors are now available in ActiveRecord. Especially readonly is interesting, it allows to store values computed by the entities in the database and is therefore the complement to a computed table column.

ActiveRecord 2.0

noreply@blogger.com (Anonymous) — Sat, 01 Aug 2009 14:39:00 +0000

Finally it’s final. I just created the ActiveRecord 2.0 zipfile.

It can be downloaded at SourceForge. This release includes the NHLinq 1.0 release.

Have Fun!

ActiveRecord Fluent Configuration

noreply@blogger.com (Anonymous) — Wed, 29 Jul 2009 06:15:00 +0000

Earlier this morning I committed a first spike of code to the actual (post 2.0) trunk of ActiveRecord. This fluent configuration shows a lot of features I am planning for 2.x releases.

Let’s take a look at the new syntax. This one is for ActiveRecord itself and mere syntactic sugar:

    1 IActiveRecordConfiguration configuration = Configure.ActiveRecord
    2     .ForWeb()
    3     .Flush(DefaultFlushType.Leave)
    4     .UseThreadScopeInfo<SampleThreadScopeInfo>()
    5     .UseSessionFactoryHolder<SampleSessionFactoryHolder>()
    6     .MakeLazyByDefault()
    7     .VerifyModels()
    8     .RegisterSearch();

The following code is however more interesting. It does not only show how AR is currently configured, but also which features will become available soon:

    1 IStorageConfiguration configuration = Configure.Storage
    2     .For
    3         .AllOtherTypes()
    4         .MappedBy(new XmlNhibernateMapping()
    5             .InAssemblyOf<OneOfMyEntities>())
    6     .As
    7         .ConnectionStringName("a_string")
    8         .Driver<SqlClientDriver>()
    9         .ConnectionProvider<DriverConnectionProvider>()
   10         .Dialect<MsSql2005Dialect>()
   11         .ProxiedBy<ProxyFactoryFactory>()
   12         .ShowSql();

The first thing to note is the interface IStorageConfiguration. Each storage configuration will be used to create a NHibernate SessionFactory.

The storage configuration consists of two parts: The database configuration is syntactic sugar for the current NHibernate configuration strings, which are a pain in the neck especially if you need to declare types.

The more interesting part is the storage type selection. The part begins in line 2 by using the For-property. The storage type selection allows you to specify which types should use the session factory created by the storage configuration and how they are mapped.

The selection above contains all classes that are not explicitly added to another storage configuration (line 3) and it says that these types are mapped using classic NHibernate mapping files (line 4) which should be loaded from a given assembly (line 5).

Line 6 finally switches back to the storage configuration.

Storage Type Selections

The storage type selection shown above is effectively a specification pattern for types. Its existence shows to consequences for future versions of ActiveRecord:

You can distribute your classes among multiple databases without the need of a common abstract baseclass. It will be possible to select the types for a storage by namespace, assembly, supertype, interfaces implemented or simply by enumerating them in the storage type selection.
ActiveRecord attributes will be only one option to map persistent types. Types mapped by HBM files or Fluent NHibernate will become first class citizens of ActiveRecord.

The specification patternfor storage type selection allows more complex combinations than currently shown. Here is another example:

    1 IStorageConfiguration auditConfig = Configure.Storage
    2     .For
    3         .SubtypesOf<AuditType>()
    4         .InNamespaceOf<DefaultAuditorType>() // logical and
    5         .MappedBy(new FluentNHibernateMapping()
    6             .InAssemblyOf<MyMappingClass>())
    7     .And // Logical or - we start the next StorageTypeSelection
    8         .TypesInAssemblyOf<MessagingImpl>()
    9         // No MappedBy defaults to ActiveRecord attributes
   10     .As
   11         .DefaultsFor<MsSqlServer2000Configuration>()
   12         .ConnectionString("server=bla;...");

Multiple selections can be created by using the And-property (line 7). Since the storage configuration holds an arbitrary number of storage type selections, this allows for a logical-or-construct. It also allows mixing different mapping types. In the example the first selection is mapped with Fluent Nhibernate (lines 5-6) and the second one with ActiveRecord attributes (line 9).

It is also possible to narrow down type selections by adding multiple specifications to a single type selection (lines 3 and 4). This means that only types are selected that satisfy all specifications. In the example only types are selected that inherit from AuditType and are in the same namespace as DefaultAuditorType.

Storage Configuration

The storage configuration (where the database is configured) is not yet as clearly defined as the storage type selection.

But it will contain default values for most database systems, a templating mechanism and special subconfigurations for fluently defining behaviour needed only occasionally, such as NHibernate Search configurations.

Does this work yet?

No. I just implemented enough to compile and run some simple tests. The features shown above will go into AR 2.1 and AR 2.2.

This article is mainly a showcase for the planned functionality. Suggestions, critic and patches are always welcome.

ActiveRecord Release Candidate

noreply@blogger.com (Anonymous) — Tue, 21 Jul 2009 16:01:00 +0000

RC 1 of ActiveRecord 2.0 is now available on SourceForge.

Unless serious bugs are found within, this version will be released as ActiveRecord 2.0 RTM on August, 1st.

German Blog reactivated

noreply@blogger.com (Anonymous) — Tue, 14 Jul 2009 17:36:00 +0000

My german blog is here.

ActiveRecord Beta 1 released

noreply@blogger.com (Anonymous) — Tue, 14 Jul 2009 17:03:00 +0000

The first beta of ActiveRecord 2.0 has been released last weekend. You can get it from Sourceforge.

Changes

Beta 1 took about two months to complete, mostly due to the number of last minute additions to the 2.0 release. The highlights are:

In-Memory-Testing

It’s now possible to test your schema without hitting a database. Inherit from our base class to specify your favorite framework’s infrastructure and the classes/assemblies to test:

    1 public class TestBase : InMemoryTest
    2 {
    3     public override Type[] GetTypes()
    4     {
    5         return new [] {typeof(Blog), typeof(Post)};
    6     }
    7 
    8     [SetUp]
    9     public override void SetUp()
   10     {
   11         base.SetUp();
   12     }
   13 
   14     [TearDown]
   15     public override void TearDown()
   16     {
   17         base.TearDown();
   18     }
   19 
   20     public override IDictionary<string, string> GetProperties()
   21     {
   22         return new Dictionary<string, string>() { {"show_sql", "true"} };
   23     }
   24 }

You can then simply create tests that don’t need a database:

    1 [TestFixture]
    2 public class CRUDTests : TestBase
    3 {
    4     [Test]
    5     public void Create()
    6     {
    7         var blog = new Blog { Name = "Blog" };
    8         blog.Save();
    9 
   10         var post = new Post { Title = "Post", Blog = blog };
   11         blog.Posts.Add(post);
   12 
   13         blog.Save();
   14     }
   15 }

Note: The tests shown above have no app.config altogether!

Basic LINQ Support

The formerly contrib project Castle.ActiveRecord.Linq has been added to ActiveRecord.

Please note that the underlying NHLinq implementation is not fully implemented. Some features are still missing, i. e. joins between unrelated entities.

NHSearch integration

If you want to search your entities, NHSearch is the right project for you. The current release simplifies usage within ActiveRecord by registering the listeners for you when you add searchable=”true” to your ActiveRecord-configuration.

More on using NHSearch can be found on this wiki page

Understand ActiveRecord mapping: Collections of simple objects

noreply@blogger.com (Anonymous) — Fri, 05 Jun 2009 16:58:00 +0000

Recently I had a post in the Castle user’s group about mapping a collection of enums with ActiveRecord. Since I know it’s just as mapping other simple types, I only referred to the documentation of the Element and ElementType properties of the HasMany attribute.

But, it turned out it is not really clear to many how to map a collection of simple values using HasMany. Therefore I decided to prepare an explanatory post, which is what you are reading now.

Mapping Basics

The problem: I want to hold a collection of enum values, say I have a status enum and want a history of that status persisted. Here is my model:

namespace EnumMapping
{
	[ActiveRecord]
	public class Article
	{
		[PrimaryKey]
		public virtual int Id { get; set; }

		[Property]
		public virtual string Author { get; set; }

		[Property]
		public virtual string Title { get; set; }

		[Property]
		public virtual Status CurrentStatus { get;set;}

		[HasMany(...)]
		public virtual IList StatusHistory
		{
			get { return statusHistory; }
			set { statusHistory = value; }
		}
		private IList statusHistory = new List();

	}

	public enum Status
	{
		None, Planned, InWriting, InEditing, Released 
	}
}

The ellipsis in the HasMany attribute is by design. I will work out in this post what you have to put here, so I let it out to make you understand the post, and not just read the code and copy and paste it.

To understand what information ActiveRecord requires to map this collection, we first will take a look into how these collections are saved in the database:

As expected, we have to tables. The Article table stores all the simple properties, but it cannot store collections. In a relational model, collections are always modeled by foreign key relations. That means we need a second table that stores both the values and the link to the article in question.

Note: You might have noticed that the StatusHistory table does not have a primary key. This is because of the bag semantics we currently have for this collection. More efficient semantics are shown later.

Looking at the StatusHistory table again, we see what we have to tell ActiveRecord to fetch the values for us and populate our List:

What is the table’s name?

We take that name and put it into the respective property of the HasMany attribute:

[HasMany(Table="StatusHistory",
	...)]
public virtual IList StatusHistory {...}

As you can see from the code, we are not through yet.

Which column refers to the article?

[HasMany(Table = "StatusHistory",
	ColumnKey = "article",
	...)]
public virtual IList StatusHistory {...}

Which column holds the value?

[HasMany(Table = "StatusHistory",
	ColumnKey = "article",
	Element = "status",
	...)]
public virtual IList StatusHistory {...}

What? There is even more to specify even though we already have all columns included?

Yes. ActiveRecord also needs to know the types of the columns. The foreign key’s column can be inferred from the types primary key, but we need to know what type the value actually has.

[HasMany(Table = "StatusHistory",
	ColumnKey = "article",
	Element = "status",
	ElementType = typeof(Status))]
public virtual IList StatusHistory {...}

That’s it (for now). We now can take that mapping and go for the database.

The Collection Types

I already mentioned the missing primary key on the collection’s table and that the collection uses bag semantics. So what are these semantics? There are a few available in ActiveRecord:

Bag: All elements are unordered and may appear multiple. Total chaos.
Set: The elements are unordered, but each one can be present only once. This is the typical relational collection.
List: Elements are ordered and may be there multiple times.
Dictionary: Elements have a key that identifies them.

If the collection type is not specified, ActiveRecord assumes that you want bag semantics. After all, that’s what a collection is. Put things in there and get them out. No one cares for ordering or duplication.

Unfortunately, this is quite inefficient with databases:Items in a bag cannot be updated individually. Recall that there is no primary key in the collection table. Since the value can be in the collection more than once, an update or delete would effect all rows with that value. As a result, every time the collection is updated, it is completely deleted from the DB and inserted again.

To get around this, we could use a set. However, this requires us to use another Collection type, Set<Status> from Iesi.Collections. So instead of a set, I will use a list semantic. This is suitable, because a status history has an implicit ordering.

To use the list semantic, the schema must be changed first, because an index column is needed to store the list’s index.

We now don’t have only an additional column, we also have a nice primary key consisting of the combination of the article’s id and the list’s index. So every value in the list can now be updated individually.

Now we must tell ActiveRecord to use list semantics and how to find the index:

[HasMany(Table = "StatusHistory",
	ColumnKey = "article",
	Element = "status",
	ElementType = typeof(Status),
	RelationType = RelationType.List,
	Index = "idx")]
public virtual IList StatusHistory {...}

That’s it.

ActiveRecord Alpha Release

noreply@blogger.com (Anonymous) — Fri, 08 May 2009 21:01:00 +0000

You will have already heard it: It is release season in the Castle’s domain.

The newest release is ActiveRecord 2.0 Alpha 1, recently uploaded to http://groups.google.com/group/castle-project-users/web/ActiveRecord2.0Alpha1.zip

This release includes a lot of breaking changes with regard to the last release, ActiveRecord 1.0 RC3, which is the main reason for going through a new complete release cycle starting with alpha releases.

This release includes a move from NHibernate 1.2 to NHibernate 2.1. Please make sure to read the Changes.txt and start testing early.

Bugs can be posted at donjon and last-minute-features can be suggested at UserVoice.

There is no feature freeze yet: All suggestions on UserVoice that get 15+ votes there until May 17th, will be considered for addition in Alpha 2. If no features take this hurdle, I will move forward to Beta 1.

Understanding ActiveRecord Sessions 2

noreply@blogger.com (Anonymous) — Thu, 23 Apr 2009 09:06:00 +0000

This article series deals with the internal session keeping of Castle ActiveRecord. This installment introduces the concept of a scope and how scopes are used within ActiveRecord.

Introducing Scopes

Having a session per database call is suboptimal. There is no chance to use transactions, which is a showstopper for most serious uses. Another issue is lazy loading: Lazy loading prevents NHibernate from loading large collections until they are requested, avoiding to load unnecessary data. Lazy loading is however only possible when done within a single session.

Castle ActiveRecord uses scopes to overcome this. A scope represents a single unit of work. It is not necessarily a single transaction, but may span multiple transactions. Prior to NHibernate 2.0, when transactions were not mandatory, scopes did not even have to support transactions.

The scopes that are part of the ActiveRecord package do always share a single session that is used for all persistance related calls. However, it is possible to implement a scope that uses a new session, but the changed semantic should be clearly communicated in such a case.

Localizing Scopes

In order to access scopes without holding a reference to the object, they stored in thread static stacks. The central interface for this is IThreadScopeInfo, which is implemented by various classes to cover different situations such as web applications. WebThreadScopeInfo for example uses a HttpContext for storing the scopes while the default ThreadScopeInfo implementation uses a thread static field.

In order to acquire the current IThreadScopeInfo implementation, ThreadScopeAccessor can be used. This class is a singleton providing the current ScopeInfo under

public IThreadScopeInfo ScopeInfo

Additionally it acts a proxy to this scope, delegating calls to the scope info in the property above. This allows to access the current scope without keeping a field for it using

ThreadScopeAccessor.Instance.XXX();

where XXX is one of the methods defined in IThreadScopeInfo.

With the IThreadScopeInfo available, the current scope can be requested by SessionFactoryHolder using the following methods:

ISessionScope GetRegisteredScope()
bool HasInitializedScope

Scope Initialization

When a scope is created, it has no sessions stored at first. That is intentional. While the ActiveRecordStarter configures the ISessionFactoryHolder at startup, it cannot configure an arbitrary number of ISessionScope implementations.

Therefore the initialization of scopes is implemented using a simple protocol between ISessionFactoryHolder and ISessionScope:

Upon creation, the ISessionScope registers itself with the current IThreadScopeInfo.
```
void IThreadScopeInfo.RegisterScope(ISessionScope scope)
```
ISessionFactoryHolder fetches the scope the next time it has to deliver a session to the ActiveRecordBase methods.
```
bool IThreadScopeInfo.HasInitializedScope
ISessionScope IThreadScopeInfo.GetRegisteredScope()
```
The ISessionFactoryHolder asks the ISessionScope whether it already has a suitable session stored. Scopes do not hold only one session. Due to different database connections by root type, they need to hold a dictionary of sessions. The scope doesn't know the key to the sessions because the key is provided by the ISessionFactoryHolder everytime a session is required.
```
bool ISessionScope.IsKeyKnown(object key)
```
If there is a session registered with the scope, the session is requested and the protocol ends.
```
ISession ISessionScope.GetSession(object key)
```
If there is no suitable session available the ISessionFactoryHolder asks the ISessionScope whether it accepts an existing session or if it wants to create its own session.
```
bool ISessionScope.WantsToCreateTheSession
```
Depending on the answer to 5, the ISessionFactoryHolder either opens a session itself or provides a suitable ISessionFactory to the ISessionScope so that the session can be created by the scope itself.
```
ISession ISessionScope.OpenSession(ISessionFactory sessionFactory, IInterceptor interceptor)
```
The session is registered with the ISessionScope by the holder. This is done regardless who in fact created the session.
```
void ISessionScope.RegisterSession(object key, ISession session)
```
The freshly registered session is fetched from the scope.
```
ISession ISessionScope.GetSession(object key)
```

The different Scope Types

Scopes generelly have two attributes that describe there behaviour: by FlushAction and by SessionScopeType. The FlushAction controls whether changes are automatically flushed to the database. The SessionScopeType describes the behaviour of the scope in common, most important whether the scope supports transactions.

If the FlushAction is defined as FlushAction.Never, no writing to the database will occur unless ISessionScope.Flush() is called by the using code. This behaviour gives full control to the using code, but requires it to control flushing. This is important: If the changes are not flushed, queries will still find an older state in the database although the entity has already changed.

FlushAction.Auto instructs the NHibernate session to flush its first-level-cache whenever needed. That means that if the cache contains an unflushed change to an entity, the session will write those changes back before it runs a query against the entity's type.

The SessionScopeType has four values:

SessionScopeType.Undefined
SessionScopeType.Simple
SessionScopeType.Transactional
SessionScopeType.Custom

Undefined should never be used; it is more an error state than a valid scope type. Simple and Transactional define whether the scope supports transactional behaviour. Custom can be used for own implementations that fall in between. An example would be a SessionScope that uses transactions only for specific sessions.

The next part of the series will show how ActiveRecord usage differs when using a scope.

Understanding ActiveRecord Sessions 1

noreply@blogger.com (Anonymous) — Tue, 21 Apr 2009 12:28:00 +0000

This article series deals with the internal session keeping of Castle ActiveRecord. It begins in explaining how sessions are managed within ActiveRecord and how the user can influence this behavior.

What happens when Save() is called?

The first part of our journey starts in ActiveRecordBase. Whenever a method is called that requires a NHibernate session, it requests one from the following field:

protected internal static ISessionFactoryHolder holder;

Since that field is marked protected internal static, subclasses of ActiveRecordBase can directly access it to acquire a session. This is done with the following methods:

ISession CreateSession(Type type);
void ReleaseSession(ISession session);
void FailSession(ISession session);

The first method requests a session from the ISessionFactoryHolder, that can be used to issue calls to the session, such as Save(), Load() etc. After the operation was completed, ReleaseSession must be called, preferably in a finally block.

If an exception is raised from NHibernate, the session cannot be used anymore. The ISessionFactoryHolder must be notified through the FailSession-method.

To further understand the inner workings of ActiveRecord, we need to look at the default implementation of ISessionFactoryHolder, which is simply called SessionFactoryHolder.

The SessionFactoryHolder keeps a dictionary which maps the configured ActiveRecord root types to ISessionFactory instances. Whenever CreateSession is called, it fetches the ISessionFactory for that type and creates an ISession.

When ReleaseSession is called the session is flushed and disposed, closing any open connections. If you use the holder to acquire sessions directly, keep in mind that it is necessary to release them or you will get a resource leak. Database sessions are among the most critical resources with regard to leaks.

If an exception is raised, the FailSession method will clear the session so that it doesn't throw again when the session is released.

When ActiveRecord is used without any scopes, all of this happens on a single call of any of the data retrieval or persistence methods (Save(), FindAll() etc.):

ActiveRecordBase gets an ISession from the SessionFactoryHolder. ActiveRecordMediator simpy calls a static method on ActiveRecordBase, so there are no differences with respect to session handling.
ActiveRecordBase performs the desired database operation.
If there is no exception, ReleaseSession is called by ActiveRecordBase. In case of an exception, FailSession is called instead and the exception is rethrown.
SessionFactoryHolder closes the ISession instance. Upon the next call, a new session is created.

But what if we need to have a single session span multiple commands? This will be handled in the following articles when we talk about scopes.

Active Record and DDD

noreply@blogger.com (Anonymous) — Tue, 27 Jan 2009 12:14:00 +0000

One of the most fatal mistakes one can conduct when beginning with Domain-Driven Design is doubling Active Record types as domain entities. This does not include Castle ActiveRecord, but all frameworks that map classes and tables one-to-one, and to some extend even more flexible solutions like NHibernate.

How does it start?

This trap is usually hit by developing a data-driven applications using ActiveRecord as an ORM. There is nothing bad with the approach per se, and I'm actually using it myself a lot. Let's see the following code taken from the Castle ActiveRecord GettingStarted section:

[ActiveRecord]
public class Blog : ActiveRecordBase<Blog>
{
	private int id;
	private String name;
	private String author;
	private IList<Post> posts = new List<Post>();

	public Blog()
	{
	}

	public Blog(String name)
	{
		this.name = name;
	}

	[PrimaryKey]
	public int Id
	{
		get { return id; }
		set { id = value; }
	}

	[Property]
	public String Name
	{
		get { return name; }
		set { name = value; }
	}

	[Property]
	public String Author
	{
		get { return author; }
		set { author = value; }
	}

	[HasMany(
		Table="Posts", ColumnKey="blogid", 
		Inverse=true, Cascade= ManyRelationCascadeEnum.AllDeleteOrphan)]
	public IList<Post> Posts
	{
		get { return posts; }
		set { posts = value; }
	}
}

This is straight forward data-driven code and there is nothing bad about it. Note that no business logic is embedded in the class. In the simple GettingStarted example, the logic is buried in the GUI, but in a real application you would perhaps use Transaction Scripts to encapsulate logic in objects.

Setting the trap

The programmer eventually reads Eric Evans great book or hears from a mailing list about DDD. He might remember that Castle ActiveRecord does not require a base class and removes it, using ActiveRecordMediator for database access.

Now that there are only POCOs, our unwary programmer starts adding business logic to the ActiveRecord types. By that, he tries to encapsulate complexity within the "domain model".

But what has happened:

Most important, he violates the Single Responsibility Principle (SRP); the class is now responsible for multiple aspects:

Storing data
Executing business logic

In the first few iterations, business logic that was previously packed in one method is now cluttered over multiple classes. DDD's supple design promises to mitigate that but a design usually only becomes supple by a lot of refactoring.

The immediate result is big step backwards in maintainability. Over the long term, DDD will have a better maintainability, but you will need a lot of work to reach this state. By that time, the trap has already sprung...

The trap fires

For a while, all will be well. The programmer get accustomed to the code and does some changes. The code gets more complex and a bit unwieldy. Finally, the programmer needs a "break-through"; a big refactoring takes place to make the code more supple.

Now, violating the SRP fires back: It is not possible to refactor the design without writing complex migration scripts for the database. Integration suddenly becomes an issue. However, the redesign is utterly needed because of the business logic embedded in the design.

The typical outcome is that the redesign is put off until "there is more time", or shorter: "never". In the meanwhile, the code base is growing and getting more and more fragile.

How to recover?

The most important task in recovering from such a dilemma is deciding which approach will be used for the application. You can choose a data-driven approach or a domain-driven approach, but not both.

Using DDD

If the complexity of the domain mandates DDD, it is necessary to do it right. This means using the ActiveRecord types as a DAO/DTO layer and building a model upon it that contains the business logic. The model is then decoupled from the data structure. If the model is redesigned, the mapping code requires to adapt, not the structure of the data storage. If the storage structure changes, the mapping code changes and not the model.

This is also the reason why it is possible to use NHibernate directly on a domain model: The NHibernate mapping files are mapping code, written in an XML-based DSL (and soon with a fluent API)

So this is the other way out of the trap when using DDD. If you use Castle ActiveRecord, take the hbm-files created when using the debug switch and use NHibernate directly instead.

Using data-driven design

It is also possible to make a full turn. A domain of modest complexity that defines most of the business cases as sequential workflows and processes, will benefit from using a data-driven approach.

The processes defined in the business domain can be modeled using the Transaction Script pattern and the Active Record model is exactly that: a pattern for accessing an underlying database.

On the "Anemic Model"

Many of the solutions above use a model that is disregarded as anemic by many. But whether a model is anemic, depends on responsibilities rather than on LOC.

Thus an ActiveRecord-model is not anemic because it is responsible for accessing the data store. A DAO/DTO is part of the persistence layer and its responsibility is passing data around. By coincidence, it doesn't need any methods for this task, but it is not anemic.

After all, violating the SRP is always worse than having an anemic model.

Disclaimer

The poor programmer who unwarily builds a trap who fired at himself was of course me.

Emulating MixIns with C#

noreply@blogger.com (Anonymous) — Wed, 19 Mar 2008 15:30:00 +0000

One of the shortcomings of C# is the missing support of MixIns, which are a popular substitute for multiple inheritance especially in Ruby. MixIns provide a way to put a common functionality in a separate classand use it in another class. That is still easy in C#, one can simply use inheritance. But, what will you do, when your classes are already inheriting from other classes? You won't want to break up your inheritance hierarchie for this, will you? Using a MixIn, you can put a common functionality in a separate class and mix it into multiple classes, regardless of their inheritance hierarchy. The methods and properties of a MixIn-class are merged into the using classes' interface and can also use the original classes members. That's the theory and what is possible in Ruby, but can it be achieved in C#? If you need an example for MixIns, you might want to read the following blog post http://www.juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/. However, you don't need any Ruby knowledge for the remainder of my post. Ok, what are the characteristics of a MixIn again:

Accessible via the using class
Has access to the using class' instance members
Must not use inheritance

Taking into account that C# is a statically and strongly typed compiled language, this is not possible at first glance. But, if all possibilities of C# are used, they can be fulfilled at least partially.

As an example, I will develop a MixIn that adds reduction-functionality to collections. Reduction is a functional programming concept means that the collection will be reduced (boiled down) to a scalar value using a user-specified delegate. Simple reductions are joining a collection of strings or adding up a collection of integers.

The following code shows how this can be implemented using a conventional static method:

    1 using System.Collections.Generic;

    3 namespace Example

4 {

    5     public delegate TItem ReduceDelegate<TItem>(

    6         TItem firstItem,

    7         TItem secondItem);

    9     public static class Reduction

   10     {

   11         public static TItem Reduce<TItem>(

   12             IEnumerable<TItem> collection,

   13             ReduceDelegate<TItem> reduceFunction)

   14         {

   15             TItem result = default(TItem);

   16             bool first = true;

   17             foreach (TItem item in collection)

   18             {

   19                 if (first)

   20                 {

   21                     result = item;

   22                     first = false;

   23                 }

   24                 else

   25                 {

   26                     result = reduceFunction(result, item);

   27                 }

   28             }

   29             return result;

   30         }

   31     }

   32 }

Now the question is, how can this functionality be implemented as a mixin. We will need at least to interfaces for this:

An interface that allows the mixin access to the using class.
An external interface that allows a client to use the functionality provided by the mixins.

The code below shows how these are declared:

    1 namespace Mixin

2 {

    3     public delegate TItem ReduceDelegate<TItem>(

    4         TItem firstItem,

    5         TItem secondItem);

    7     public interface IReduceClient<TItem> : IEnumerable<TItem>{}

    9     public interface IReduceMixin<TItem>

   10     {

   11         TItem Reduce(ReduceDelegate<TItem> reduceFunction);

   12     }

   14     public interface IWithReduce<TItem> : IReduceClient<TItem>, IReduceMixin<TItem> {}

   16     public class ReduceMixin<TItem> : IReduceMixin<TItem>

   17     {

   18         public ReduceMixin(IReduceClient<TItem> client)

   19         {

   20             this.client = client;

   21         }

   23         private readonly IReduceClient<TItem> client;

   25         public TItem Reduce(ReduceDelegate<TItem> reduceFunction)

   26         {

   27             TItem result = default(TItem);

   28             bool first = true;

   29             foreach (TItem item in client)

   30             {

   31                 if (first)

   32                 {

   33                     result = item;

   34                     first = false;

   35                 }

   36                 else

   37                 {

   38                     result = reduceFunction(result, item);

   39                 }

   40             }

   41             return result;

   42         }

   43     }

   44 }

Line 7 declares the interface that the mixin uses to access the using class (IReduceClient). This can be arbitrary complex, but in this case, we only need an enumeration, so I just inherited from IEnumerable. Line 9 declares the interface that is publicly used to access the mixin's functionality (IReduceMixin). IWithReduce on line 14 just brackets the other two interfaces, so that an using class can specify IWithReduce, which shows the intention better than using the two different interfaces.

The mixin class is shown on lines 16ff. It simply holds a reference to the client, a.k.a. the using class and the Reduce implementation shown above.

Now the problem is how can the mixin added to a client. The code below would be ideal, but won't work with C# 2.0:

    1 namespace Client

2 {

    3     public class ReducableList<T> : List<T>, IWithReduce<T>

    4     {

    5         // Won't work that way!

    6     }

7 }

Before I show a (naive) implementation, here is the test code for the whole thing, that shows how it is used:

    1 namespace Test

2 {

    3     [TestFixture]

    4     public class ReduceTest

    5     {

    6         [Test]

    7         public void TestMixin()

    8         {

    9             ReducableList<string> rl = new ReducableList<string>();

   10             rl.AddRange(new string[] {"a", "b", "c"});

   12             IReduceMixin<string> reducable = rl;

   13             Assert.AreEqual("a,b,c", reducable.Reduce(delegate(string s1, string s2) { return s1 + "," + s2; }));

   15             ReducableList<int> rli = new ReducableList<int>();

   16             rli.AddRange(new int[] {1, 2, 3, 4});

   17             Assert.AreEqual(10, rli.Reduce(delegate(int i, int j) { return i + j; }));

   18         }

   19     }

   20 }

R# Jedi

One simple, naive and somewhat cheating method to make the ReducableList work, is using ReSharper. Just add a IRecudeMixin field and choose Alt+Ins/Delegate members. As a finishing touch you need to initialize the field.

The resulting code is shown below:

    1 namespace Client

2 {

    3     public class ReducableList<T> : List<T>, IWithReduce<T>

    4     {

    5         public ReducableList()

    6         {

    7             reducer = new ReduceMixin<T>(this);

    8         }

   10         // Other constructors omitted for brevity

   12         private readonly ReduceMixin<T> reducer;

   14         public T Reduce(ReduceDelegate<T> reduceFunction)

   15         {

   16             return reducer.Reduce(reduceFunction);

   17         }

   18     }

   19 }

Well, I know that this is not a viable solution for maintainable software, but it is at least a quick fix and an introduction for the next article, which will show how to use DynamicProxy2 for creating a ReducableList without ReSharper Jedi.

The Component Burden Concept

noreply@blogger.com (Anonymous) — Thu, 28 Feb 2008 07:51:00 +0000

Important Note: Mort that I am, I have mistaken ReleasePolicy for Component Burden and blogged about the former... As soon as I know what I am writing about, I will update that post.

There is a discussion on the Castle mailing list recently about the Component Burden problem. This is one of the oldest Castle issues (and the oldest that is not resolved by now). Now, the issue got a little bit of momentum by Ayende's post and Hammett's blog entry about it.

In short, the problem is this: If there are non-singleton components created by the IoC-Container that implement IDisposable, someone sometime needs to call Dispose(). However, both someone and sometime pose a problem:

Someone could be the using code or the container. It has been proposed that a component should dispose it's dependencies itself, but if you think about it, this is problematic because the component cannot know it's dependencies' lifestyles. Just imagine a service configured to run as a singleton being disposed after the very first request it served, because an using component doesn't need it anymore. Additionally there is a simple principle about resource allocation: The code that allocates a resource is responsible for deallocation too. Period. Back when C/C++ was used, every developer adhered to that principle because there was no GC...
Sometime is dependent on the components lifestyle. A singleton must not be disposed before the container shuts down itself while a transient component must be disposed as soon as possible to free allocated resources.

Now it is clear that the container is fully responsible for both construction and destruction of dependency objects. But how will it know, when the component is not used anymore?

Well, at least one component must be resolved from the container. This component must be released after you are finished using it:

MyComponent c = container.Resolve<MyComponent>(); // Some work container.Release(c);

Do you need to do this even if you're component is not disposable? Yes, because it can have direct or indirect dependencies that are disposable. If you don't release it, the container cannot know that it is now safe to dispose these dependencies, when they are otherwise unused.

Now there is one thing missing: The container must keep track of the dependencies. Assume that your component uses a custom per-web-request-logger that uses a FileStream.

Every time you resolve a component that uses the logger in one web request, the dependency will be fulfilled with the same logger. If you release a component, the container must remember that it used the logger, then check whether the logger is still used by other instances and if not, dispose the logger.

This bookkeeping of dependencies and disposal is called the component burden in the Castle project.

Although I don't know Microkernel's source code for this, I have an idea how to implement such a concept. But this is a topic for another post.

WTF: Overloading and Generics

noreply@blogger.com (Anonymous) — Fri, 09 Nov 2007 13:03:00 +0000

Recently I discovered some behaviour of .NET that I couldn't explain. I still wonder whether this is an error or "ByDesign". I found it when I tried to call ActiveRecordMediator's Exists method, which threw out an unexpected exception. Minutes later, I stared unbelievingly to the screen: A complete different method overload was called. I sat down and created a short example that doesn't use ActiveRecord, so it can be understood from any .NET-developer:

public interface IString
{
  string Content{ get;}
}

public class DString:IString
{
  private readonly string content;

  public string Content
  {
    get { return content; }
  }

  public DString(string content)
  {
    this.content = content;
  }
}

public static class Class1
{
  public static void Foo(params IString[] bars)
  {
    foreach (IString s in bars)
    {
      Console.WriteLine(s.Content);
    }
  }

  public static void Foo<T>(T bar)
  {
    throw new NotImplementedException();
  }

}

[TestFixture]
public class Tester
{
  [Test]
  public void CallBar()
  {
    Class1.Foo(new DString("baz"));
  }
}

So what would you expect when running the unit test? That's what I got: TestCase 'ClassLibrary2.Tester.CallBar' failed: System.NotImplementedException : The method or operation is not implemented. What happens here? If you add exactly one optional parameter, the compiler somehow thinks, you meant Foo<istring>() instead of Foo(). This happens only if the type parameter is an interface. I tried with string and that worked like expected, calling Foo(). So, is this a bug or a documented behaviour. Do you know ressources that document it? I didn't find any...

From The Book of Ideas: Searchable ActiveRecord-Entities

noreply@blogger.com (Anonymous) — Tue, 06 Nov 2007 11:26:00 +0000

One of the feature requests that I hear most often from my users that they want a search function for the grids. I then show them a search form where they can specify field and values exactly. Most often, I then hear: "No, I meant a search field. I enter some text and the software shows all relevant entries." I usually answer by asking whether it should also save the climate and overcome poverty or if simple mindreading is sufficient. Ok, but last night I had an idea how searching with a single textfield interface can be accomplished without redeveloping that nasty thing for each view. I use the Castle stack for .Net for my applications, which means that my entities are created with Castle ActiveRecord and displayed in MonoRail web applications. The idea works like this: There is only one who knows which properties must be included into the search and this the developer that created the entities. Therefore we need some mechanism to specify the searchable properties. My idea was adding a Searchable attribute to the ActiveRecord classes' properties that need to be included in such searches:

    [ActiveRecord]
    public class Entity : ActiveRecordBase<Entity>
    {
        private int id;
        private string name;
        private string entityDesc;
        private string internalName;

        [PrimaryKey]
        public int Id
        {
            get { return id; }
            set { id = value; }
        }

        [Searchable][Property]
        public string Name
        {
            get { return name; }
            set { name = value; }
        }

        [Searchable(FriendlyName = "Description")][Property]
        public string EntityDesc
        {
            get { return entityDesc; }
            set { entityDesc = value; }
        }

        [Property]
        public string InternalName
        {
            get { return internalName; }
            set { internalName = value; }
        }
    }

The Searchable takes an optional parameter, FriendlyName that allows to specify a localized or other, more user-friendly name. The attribute can be applied to both properties and relations. If applied to a relation attribute (BelongsTo, HasMany, HasAndBelongsToMany etc.) the properties tagged in that type will be added to the search as well. Then there is a SearchMediator, which will create a NHibernate Criteria Query that will check for every search term whether it can be parsed by the datatype of a tagged property and adds it to the query if this is the case. The code below sketches how the query could be created:

public static T[] Search(string text)
{
    string[] words = text.Split();
    DetachedCriteria criteria = DetachedCriteria.For<T>();
    foreach (string word in words)
    {
        Disjunction group = Expression.Disjunction();
        foreach (PropertyInfo info in typeof (T).GetProperties())
        {
            if (info.GetCustomAttributes(typeof (SearchableAttribute), true).Length > 0)
                group.Add(Expression.Like(info.Name, word, MatchMode.Anywhere));
        }
        criteria.Add(group);
    }
    return ActiveRecordMediator<T>.FindAll(criteria);
}

This can be extended by many means. Examples include:

Allowing propertyName:searchTerm to narrow search to a specific property by its name or friendly name.
Allowing other operators than the colon like price>10.00 or name!Foo
Add globbing to specify whether exact matches or all matches should be found
Specify the MatchMode behavior for string properties as part of SearchableAttribute

Using that mechanism, I can add searching to almost any entity similar to validation. What do you think, would such a Search component benefit the Castle Framework?

That is only some thoughts. I didn't start implementing anything yet. However, anyone interested in helping is welcome, of course.