I've put up some of my multi monitor wallpapers at frozentear.com. If you develop on a 3200x1200 screen you might want to check this out. No promises, I'm a coder not an artist. :)
Liked this post? Subscribe to my feed.
Incredibly simple, but quite useful:
public static void Save(this ISession session, params object [] entities)
{
foreach (var o in entities)
{
session.Save(o);
}
}
You can use it like:
session.Save(a,b,c,d,....);
with a list of objects of any type. Useful for unit testing where you want to save multiple items at once.
[Update]
Probably should call it something other than Save, such as SaveAll or SaveList because if you only pass two items to the overload it calls the standard Save(object, int id) version. :(
Liked this post? Subscribe to my feed.
If you're running into this error in NHibernate:
System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: Attempting to parse a null value into an sql string.
Examine your mappings for abstract classes that aren't implemented, or classes that are marked as abstract in the mappings but not in the c# file. I was refactoring out some abstract classes in the middle and forgot to delete the abstract="true" line in the mapping.
Liked this post? Subscribe to my feed.
I've had it with Foo and Bar. They are right out. For too long we programmers have put up with these sorry excuses for example classes in documentation, lectures, examples, and now that TDD is all the rage, tests.
There is no standard for the relationship of Foo and Bar.
Standards in examples and relationships are full of time-saving goodness. Take for example the Northwind database. Recently there's been a big push for replacing Northwind with some other database standard. One of the chief arguments against the "Not Northwind" mafia are the magic words, "I'm using Northwind for my database". *Poof* everyone in the audience knows the relationships inherent in the system.
But Foo and Bar have no default relationship. In the NHibernate project there are 8 different Foo classes, 2 Bars, and 1 FooBar. One of those is actually even in the NHibernate.DomainModel namespace, most of the remainder are in the SpecificTest folder. Different developers have created tests relying on Foo and Bar, and when debugging these tests I have no idea what the properties, entities, or relationships should be.
A sampling of different properties shows that some Foos have Descriptions, while others have Names, Words, Numbers. Some have other Foo as children, while others have Bar as children. Sometimes a FooBar will have a Foo or Bar property....
Enough!
Please, if you submit a patch to an Open Source project... or any project for that matter, don't use Foo or Bar. Use People and Pets, Cities and Houses, Sales Orders and Sales Line Items, Customers and Orders... any number of obvious relationships that readers won't need to review the class in order to understand. Foo and Bar slow the reader down... even if you're the one that wrote it.
Liked this post? Subscribe to my feed.
W00t! I've been accepted as a developer of NHibernate. I'm looking forward to helping this project move along as I discover things that I can fix...
Liked this post? Subscribe to my feed.
Your website might suck if... it contains the words click here.
...
Of course... now mine does. Doh!
Liked this post? Subscribe to my feed.
This simple function cleans up a lot of the Alias sillyness I have fought with in NHibernate.
public static ICriteria CriteriaByLongAlias(this ICriteria criteria, string field)
{
ICriteria byAlias = criteria.GetCriteriaByAlias(criteria.Alias + "_" + field) ??
criteria.CreateCriteria(field, criteria.Alias + "_" + field);
return byAlias;
}
It is used any time you would previously call CreateCriteria and pass an alias.
Before:
session.CreateCriteria(typeof (Product)).CreateCriteria("Orders","Product_Orders");
After:
session.CreateCriteria(typeof(Product)).CriteriaByLongAlias("Orders");
The alias part is done automatically based on the criteria path. The advantage is that it works recursively, allowing for multiple criteria to be created, and then referenced without duplicates.
ICriteria criteria = session.CreateCriteria(typeof(Product)).CriteriaByLongAlias("Orders").CriteriaByLongAlias("Customer").Add(Expression.Eq("Name", "Ace Hardware"));
criteria.CriteriaByLongAlias("Orders").Add(Expression.Eq("OrderNumber",12354));
etc.
Note that in order for it to work, you have to create all your subcriteria with it.
-Will
Liked this post? Subscribe to my feed.
Here's an extension to Assembly that I found useful for finding a type. I recommend doing
typeof(TypeInAssembly).Assembly.FindType("typename");
public static class AssemblyExtensions
{
public static Type FindType(this Assembly assembly, string typename)
{
return assembly.FindTypes(typename).FirstOrDefault();
}
public static Type[] FindTypes(this Assembly assembly, string typename)
{
Type[] types = assembly.GetExportedTypes();
List<Type> found = new List<Type>();
foreach(Type type in types)
{
if(type.Name == typename)
{
found.Add(type);
}
}
return found.ToArray();
}
}
Liked this post? Subscribe to my feed.
Liked this post? Subscribe to my feed.
Thanks for the ohhh so useful error message SQL server team.
Ass.
Liked this post? Subscribe to my feed.