Update May 25, 2007: ActiveRecord now supports DetachedCriteria, which eliminates the need for the SlicedFindAll that I wrote below. It is nice when a library moves to add support for such commonly needed functions. So in summary, use Detached criteria instead of the code below. It is still a nice example of using NHibernate sessions.
I have a history log, where each history record "belongs to" a service record. I have to treat this as a child-to-parent join, since some children are orphans. I wanted to use the FindAll(Criteria), but I wanted the option to have optional criteria, orders and aliases. My solution was to create an ARAlias class to represent an Associated Entity and an alias, and then build an ARBusinessBase class with the following method:
The ActiveRecordBase methods in svn trunk allow you to supply a null for the Order[] array, but not for Criteria (in that case, they require an empty placeholder array. My method is more consistent, and allows null for any array. So if I do not need to do an "ORDER BY", I can do ...
rather than ...
Either way works. My ARAlias class just attaches itself to the query's criteria by calling sessionCriteria.CreateAlias(associatedEntityName, aliasName). Here is the code for the ARAlias class:
I might make contact with the ActiveRecord maintainer, and see if there is any interest in adding something like this to the mainline. I would have to build a patch for ActiveRecordBase, adding the non-generic base methods and calling them from the generic child type. In my code, I have ARSortOrder, ARAlias and ARCriterion. My ARCriterion class is very weak, but the ARSortOrder and ARAlias classes seem to work nicely in my application. My current ARCriterion is more of a "Builder" class that allows the user of my application to select a property, an equality condition like LESS_THAN or EQUALS, and a value or entity, and create a Criterion from that. I will not pretend that my augmentation of ActiveRecord's Criteria support eliminates the need for HQL, but it dramatically reduces it.
I have a history log, where each history record "belongs to" a service record. I have to treat this as a child-to-parent join, since some children are orphans. I wanted to use the FindAll(Criteria), but I wanted the option to have optional criteria, orders and aliases. My solution was to create an ARAlias class to represent an Associated Entity and an alias, and then build an ARBusinessBase
public static T[] SlicedFindAll(int firstResult, int maxResults,
Order[] orders, ARAlias[] aliases, params ICriterion[] criteria)
{
IList list = null;
ISessionFactoryHolder holder = ActiveRecordMediator.GetSessionFactoryHolder();
ISession session = holder.CreateSession(typeof(T));
try
{
ICriteria sessionCriteria = session.CreateCriteria(typeof(T));
if (aliases != null)
{
foreach (ARAlias alias in aliases)
{
alias.AttachTo(sessionCriteria);
}
}
if (criteria != null)
{
foreach (ICriterion cond in criteria)
{
sessionCriteria.Add(cond);
}
}
if (orders != null)
{
foreach (Order order in orders)
{
sessionCriteria.AddOrder(order);
}
}
sessionCriteria.SetFirstResult(firstResult);
sessionCriteria.SetMaxResults(maxResults);
list = SupportingUtils.BuildArray(typeof(T), sessionCriteria.List());
}
catch (ValidationException)
{
throw;
}
catch (Exception ex)
{
throw new ActiveRecordException("Could not perform SlicedFindAll for "
+ typeof(T).Name, ex);
}
finally
{
holder.ReleaseSession(session);
}
return (T[])list;
}
The ActiveRecordBase methods in svn trunk allow you to supply a null for the Order[] array, but not for Criteria (in that case, they require an empty placeholder array. My method is more consistent, and allows null for any array. So if I do not need to do an "ORDER BY", I can do ...
IList list = History.SlicedFindAll(0, 10, null, null, myCriterionList);
rather than ...
IList list = History.SlicedFindAll(0, 10, new ARAlias[] {}, new Order[] {}, myCriterionList);
Either way works. My ARAlias class just attaches itself to the query's criteria by calling sessionCriteria.CreateAlias(associatedEntityName, aliasName). Here is the code for the ARAlias class:
using System;
using System.Collections.Generic;
using System.Text;
using NHibernate;
using NHibernate.SqlCommand;
namespace LearningByDoing.ActiveRecord.Support
{
// represents an alias to be added to a Criteria search
public class ARAlias
{
private string _associationPath;
private string _alias;
private JoinType _joinType;
public ARAlias(string associationPath, string alias)
{
_associationPath = associationPath;
_alias = alias;
_joinType = JoinType.InnerJoin;
}
public ARAlias(string associationPath, string alias, JoinType joinType)
{
_associationPath = associationPath;
_alias = alias;
_joinType = joinType;
}
public ICriteria AttachTo(ICriteria criteria)
{
// apparently, this creates and attaches the alias to the supplied criteria
criteria.CreateAlias(_associationPath, _alias, _joinType);
return criteria;
}
}
}
I might make contact with the ActiveRecord maintainer, and see if there is any interest in adding something like this to the mainline. I would have to build a patch for ActiveRecordBase, adding the non-generic base methods and calling them from the generic child type. In my code, I have ARSortOrder, ARAlias and ARCriterion. My ARCriterion class is very weak, but the ARSortOrder and ARAlias classes seem to work nicely in my application. My current ARCriterion is more of a "Builder" class that allows the user of my application to select a property, an equality condition like LESS_THAN or EQUALS, and a value or entity, and create a Criterion from that. I will not pretend that my augmentation of ActiveRecord's Criteria support eliminates the need for HQL, but it dramatically reduces it.
Comments