IoC 29 - Required to make Binsor work, has moved (with changes from Hammett), to the trunk. I've update Rhino Commons with the new changes, and now you can use it with the Windsor from Castle's trunk.
Have fun...
I just had a converstion with a friend of mine, that started like this:
Her: (accusing) "Why didn't you call to say happy new year*?"
Me: "I don't call anyone to say that."
Her: "It is good that you didn't call, I hate when people do that."
Damned if I do, and damned if I don't. God help me if I could ever understand women.
* It is the Jewish new year.
The blog was down for about half an hour while I updated to dasBlog 1.9. You should be able to notice a major speedup.
The nice feature that I really want is the tag cloud support, but I can't figure out how to make it work, I added it to the theme, but it isn't outputting anything. You should notice the nice category view, though.
Just read this post, talking about a problem with generating valid XML for IE using Brail. The issue is that Brail considers <? ?> as code blocks markers, thus completely disabling support for xml processing instructions.
This is a breaking change in Brail, but I feel that the reason for removing them is strong enough to do so. If you have got Brail code that uses <? ?>, you need to replace it to either <% %> (not recommended) or <?brail ?> (recommended, valid XML). If this is a really big issue for you, please inform me, and I'll create a compatability mode.
And Ken, I couldn't post any comments to your blog for some reason.
I just good a Happy New Year email from a company I bought some nonsense from about three years ago. Leaving aside the fact that I contains no memory of why I was in their distribution list, I have posted below all the emails that were in the To field. This is at 40% resolution, and it was enough to fill up a whole page in word.
Way to go.
A while ago I needed to test the output of a class that wrote data to a file. I didn't want to start reading/ writing files in my tests, so I created the following interface:
public interface IOutputFactory
{
TextWriter Create(string name);
}
This was easy to mock, and I could get the output back very easily. I didn't gave it much thought afterward, except to cuckle a bit at this interface's purpose. The implementation was simple:
Then, I got a new requirement from the customer: When I finish writing to a file, I should rename it using a pre-defined pattern. I really have no idea how I would have found all the file I/O operations in this application, but using the approach above, I created a RenamingTextWriter, which would rename the output file when it is closed. That change was a matter of minutes, as was the change to add application wide enconding to the file.
In Working With Legacy Code, Michael talks quite a bit about the seams of the system, where you can insert your mocks and start testing. What I have found is that those seams are very useful for adding functionality, the above case is fairly simple, but I'm using the same approach quite a bit all over the place.
No, really for real this time. I opened my mailbox today to find a very interesting message from the NHibernate commit logs:
NH-258 - Custom SQL support (including stored procedures)
It may look fairly innocent comment, but it has quite an impact on several nay-sayers that will clutch stored procedures until you pry them out of their cold dead hands. Also, sometimes Stored Procedures (or raw SQL) are useful :-).
So, armed with nothing but a toothpick and some shoes' polish, I turned to the task of finding out how to use this wonderous new feature. I started on the Hibernate documentation in the subject
The table model is very simple:
I then create a simple set of stored procedures, all of which were fairly standard, like this one:
ALTER PROCEDURE [dbo].[EmployeesInsert](
@Name nvarchar(50), @Surname nvarchar(50),
@Email nvarchar(50), @Type int, @Id int
)
AS
INSERT INTO [Employees]
(
[Id], [Name], [Surname], [Email], [Type]
)
VALUES
(
@Id, @Name, @Surname, @Email, @Type
)
RETURN @@Error
I have created those procedures via code generations, but I think that you'll agree that most existing stored procedures will have a similar look. I have the following SPs:
· EmployeesInsert
· EmployeesUpdate
· EmployeesDelete
· SalariesInsert
· SalariesUpdate
· SalariesDelete
The only slightly strange thing about these procedures is the position of the ID parameter. While in most SP it is the first parameter, it seems that NHibernate requires it to be the last parameter on the stored procedure. Also note that specifying SET NOCOUNT ON will cause NHibernate to think that it didn't manage to save the row, and throw. The SP must return a count of 1.
So, given those, how am I going to proceed?
First thing that I should do it to update the XSD schemas, this is so I could get intellisense inside VS.Net when I edit the mapping files. Then, let us create our entites:
This is a fairly simple model to grasp, but hard to implement. I'll not show you everything, but I'll at least put you on the right path. Let us start with mapping the Employee class:
<class name="Employee"
table="Employees"
discriminator-value="1"
lazy="true">
<id name="Id"
unsaved-value="0">
<generator class="assigned"/>
</id>
<discriminator column="Type"/>
<property name="Name"/>
<property name="Surname"/>
<property name="Email"/>
<set name="Salaries"
generic="true">
<key column="EmployeeId"/>
<one-to-many class="Salary"/>
<loader query-ref="allSalariesForEmployee"/>
</set>
<subclass name="Manager"
discriminator-value="2">
<sql-insert>
exec EmployeesInsert ?,?,?,2,?
</sql-insert>
</subclass>
<sql-insert>
exec EmployeesInsert ?,?,?,1,?
</sql-insert>
</class>
This is mostly standard NHibernate mapping, with some interesting additions, notice the generic="true" in the set defination? That means that you can use ISet<T> without using NHibernate.Generics.
Now, for now, let us ignore the <loader> in the set element, and look at the bottom of the code, where we find a <sql-insert> statement, which directs NHibernate to use the text inside when it is inserting an entity to the database. A couple of points about the question marks before we continue:
NHibernate transforms this call to:
exec
EmployeesInsert @p0,@p1,@p2,1,@p3As I have no real control on the order of the parameters, my SP needs to be changed approprirately (above it appears after the changes). Now, about managers, you noticed that I specified a different statement there? That allows me to pass the different discriminator value (or maybe call ManagersInsert), etc.
Before we get to the set mystery, let us take a look at how I mapped Salary:
<class name="Salary"
discriminator-value="-1">
<id name="Id">
<generator class="assigned"/>
</id>
<discriminator column="Type"/>
<property name="Remark"/>
<many-to-one name="Employee"
class="Employee"
column="EmployeeId"/>
<subclass name="HourlySalary"
discriminator-value="1">
<property name="HourlyRate"
column="ParameterOne"/>
<sql-insert>
exec SalariesInsert ?,?,?,1,?
</sql-insert>
</subclass>
<subclass name="GlobalSalary"
discriminator-value="2">
<property name="TotalSalary"
column="ParameterOne"/>
<sql-insert>
exec SalariesInsert ?,?,?,2,?
</sql-insert>
</subclass>
<sql-insert>
raiserror ('Salary is an abstract type, can''t insert it!',10,1)
</sql-insert>
</class>
This is not very different, isn't it? Notice that because salary is an abstract type, I raise an error if an attempt is made to save it (not really neccecary, since this is not possible, but whatever). Then, each subclass defined each own insert statement.
One thing to notice here is the parameter orderring. It appears that in this case the orderring is in the order defined in the mapping, in reverse hierarchal depth. Which means that the members of the subclass appear first, and then the members of the parent class, and last (but not least) the id.
For reference, here is the SalariesInsert procedure:
ALTER PROCEDURE [dbo].[SalariesInsert]
(
@ParameterOne int, @Remark nvarchar(50),
@EmployeeId int, @Type int, @Id int
)
AS
INSERT INTO [Salaries]
(
[Id], [Type], [ParameterOne], [Remark], [EmployeeId]
)
VALUES
(
@Id, @Type, @ParameterOne, @Remark, @EmployeeId
)
RETURN @@Error
Now, let us check that facinating association between employees and salaries:
This means that when NHibernate wants to load the employees' salaries, it needs to execute the query (not SP) that is specified. In this case, here is the query:
<sql-query name="allSalariesForEmployee">
<load-collection alias="salaries"
role ="Employee.Salaries"/>
exec [SalariesByEmployeeId] ?
</sql-query>
Note that we need to specify which collection this query resolves. The SalariesByEmployeeId is simply:
ALTER PROCEDURE [dbo].[SalariesByEmployeeId]
(
@EmployeeId int
)
AS
SELECT
[Id], [Type], [ParameterOne], [Remark], [EmployeeId]
FROM [Salaries]
WHERE [EmployeeId] = @EmployeeId
So, that is all that I have to say so far, you can check Hibernate's documentation for all of the details, and check out the latest NHibernate code to play with it.
This is probably not going to help you map directly to pre-existing stored procedures, but it make it that much easier to work in those envrionment where you just can't get the data from the tables (for various reasons, not the least of which is the 160 columns table), or where Stored Procedures are mandated.
I'm very excited by this because I know that there are several places where this can be very helpful. I love PIVOT, and it was annoying not to be able to use it from NHibernate.
The disadvantages - You take away from NHibernate the ability to comprehend the structure of the tables, this mean that it can't do joins, eager fetching, etc. This is extremely important capability that just vanished. Likewise for queries, NHibernate's abilities to query your objects is being severly limited using this method of operation.
You may have noticed that I have create some wrappers around NHibernate, to make it easier to work with. NHibernate's API is very rich, and it can get pretty long if you are not careful. Consider the following:
Session.CreateCriteria(typeof(Post))
.Add(Expression.Gt("PostedAt", DateTime.Now.AddDays(-3)))
.Add(Expression.Eq("ShowInMainPage", true))
.AddOrder(Order.Desc("PostedAt"))
.SetFirstResult(0)
.SetMaxResults(25)
.List();
The above is very clear way, if long winded, to say "give me the last 25 posts in the last 3 days that should be shown in the main page". I swim around this API like fish in the water, until it comes to testing.
Trying to mock the above sentence is a PITA of the first order, and I say this as someone who wrote a mocking library :-)
Partly because of this, partly because I liked the API from Active Record, partly because I wanted a mode DDD model to work with, and partly because a client wanted to avoid commitment to a specific OR/M, I created a wrapper around it that gave some very nice features, adding code generation didn't hurt, so the above query now looks like this:
Repository<Post>.FindAll(0,25,Order.Desc("PostedAt"),
Where.Post.PostedAt.Gt(DateTime.Now.AddDays(-3)),
Where.Post.ShowInMainPage.Eq(true));
Using the Repository<T> is very simple, you can check the API here:
Most of the saving are done by removing the fluent interface, and while I feel that this is simpler in most cases, there are some things that it just can't express.
I have talked before about cachable queries, in NHibernate, the are expressed by calling SetCachable(true), and setting the Cache Region, if neccecary. My API doesn't allow for it. Oh, I could add another parameter, but I already have a possible parameter explosion (check out the number of overloads on FindAll() ), and going this route would force me to add a parameter that would force bypassing the cache, etc.
Clearly, NHibernate's approach is much more reasonable now, it is easily extensible to support more options, and it doesn't break down when the complexity goes up.
I really like the fact that I have intellisense at my hands, and that I don't have to scroll through the 50+ methods (I counted) that some of the interfaces in NHibernate have. In addition to that, I have a problem where I want to cache a particular query, part of the time, and only for a very specific part of the time. In the part in question the queryis called roughly 3,650,000 times during the process of executing a certain web request [three points to the first fellow who can tell me what I'm doing]. Obviously going to the database per each query isn't going to be worth my time.
This query is sitting very low in the stack, and I really don't want to have to change / modify it in place, and I don't really like the idea of a caching version vs. non-caching version. After getting up and hitting the wall a couple of time with someone else head (What, you expected me to use mine? I use it for thinking. :-) ), I came up with the following solution:
The usage is fairly simple:
using(With.QueryCache())
{
ICollection<Post> postsToShow = Repository<Post>.FindAll(0, 25, Order.Desc("PostedAt"),
Where.Post.PostedAt.Gt(DateTime.Now.AddDays(-3)),
Where.Post.ShowInMainPage.Eq(true));
}
I'll be the first to admit that the "using(With ..." syntax is not the best there is, but in this case, I don't need to special case the exception case, so I don't think that I need to use a function that takes a delegate here.
The really interesting part is the TemporaryQueryCache(), which will enable the query cache for the duration of the using() statement. This means that I can selectively turn it on/off for a part of the code that require caching without actually modifying any code lower in the stack. This enables me to make much better decisions with regard to how and when I can use caching.
I commited my changes, but they are still in the proof of concept stage, and may change.
You can check them out here, or check out the entire tree using:
svn co http://svn.berlios.de/svnroot/repos/rhino-mocks/trunk/rhino-commons
Take a look at this, it certainly looks cool. I'm trying it out at the moment, I had to enlarge the font size a bit, probably because I'm on 1280x1024 on these monitors.
Life gets interesting with creative spelling error. I was checking a problem with a page today when I noticed the... interesting name it had... "EmployeeAssassinationValidatorRules.aspx"
No, I don't work on that kind of system.
The name should haved been named "EmployeeAssignationValidatorRules.aspx", or better yet, "EmployeeAssignmentsValidatorRules.aspx". But creative mispelling and taking the first result from Babylon spelling fixer.
I wonder what would happen if I didn't both to actually read the page name, how long it would go unnoticed...
No future posts left, oh my!
+972 52-548-6969
