sorted by: recent | see : popular

Content Tagged with NHibernate + SQL

I found myself trying to fix a bug in the nHibernate source today.With nHibernate its a pleasure to have a lot of unit tests to make sure you (hopefully) haven't broken anything with your changes. I did what i always do, checked out the nHibernate trunk ran all the tests and no failures. Then i messed around with the source made some changes and wanted to make sure all tests still passed. However in the middle of my fiddling i had dropped the nHibernate database used for unittests and recreated it, but that shouldn't be a problem. nHibernate creates tables needed during its unit testing so all is good.

Then a test failed, and this test had nothing to do with the things i worked on, so i went to investigate the failing testcase called NHibernate.Test.SubselectFetchTest.SubselectFetchFixture.SubselectFetchWithLimit the testcase tries to fetch 2 rows from the database out of tree added and do various asserts on their children to check that collection fetching using the subselect fetch strategy is working. The assertion that failed was that a wrong number of child elements were on one of the parents, and a little investigation showed that the 2 rows returned was not the ones the test expected. To reproduce the error a test like this could be written:

[Test]
public void WrongElementReturnedFromLimitQuery()
{
	//Save three objects to the database with different names
	ISession s = OpenSession();
	Parent p1 = new Parent("foo");
	Parent p2 = new Parent("bar");
	Parent p3 = new Parent("aaa");
	s.Save(p1);
	s.Save(p2);
	s.Save(p3);

	s.Flush();

	IList<Parent> parents = s.CreateQuery("from Parent order by Name desc")
				.SetMaxResults(2)
				.List<Parent>();
	Assert.Equal("foo", parents[0].Name); //Fails expected "foo" was "aaa"
	Assert.Equal("bar", parents[1].Name); // Fails expected "bar" was "foo"
}

I was a bit puzzled at first, these sort of queries in nHibernate is pretty well tested and as i said i had not changed anything related to this, but to be sure i quickly reverted my changes and ran the tests again. And it still failed... Then i suddenly realised what was wrong and why this test suddenly failed. Take a moment and give me your guess on why... 

Yep, you guessed it. My new database running the tests were created using danish collation for sorting and in denmark aa is the same as the danish charecter å which is last in the alphabeth.

I found myself trying to fix a bug in the nHibernate source today.With nHibernate its a pleasure to have a lot of unit tests to make sure you (hopefully) haven't broken anything with your changes. I did what i always do, checked out the nHibernate trunk ran all the tests and no failures. Then i messed around with the source made some changes and wanted to make sure all tests still passed. However in the middle of my fiddling i had dropped the nHibernate database used for unittests and recreated it, but that shouldn't be a problem. nHibernate creates tables needed during its unit testing so all is good.

Then a test failed, and this test had nothing to do with the things i worked on, so i went to investigate the failing testcase called NHibernate.Test.SubselectFetchTest.SubselectFetchFixture.SubselectFetchWithLimit the testcase tries to fetch 2 rows from the database out of tree added and do various asserts on their children to check that collection fetching using the subselect fetch strategy is working. The assertion that failed was that a wrong number of child elements were on one of the parents, and a little investigation showed that the 2 rows returned was not the ones the test expected. To reproduce the error a test like this could be written:

[Test]
public void WrongElementReturnedFromLimitQuery()
{
	//Save three objects to the database with different names
	ISession s = OpenSession();
	Parent p1 = new Parent("foo");
	Parent p2 = new Parent("bar");
	Parent p3 = new Parent("aaa");
	s.Save(p1);
	s.Save(p2);
	s.Save(p3);

	s.Flush();

	IList<Parent> parents = s.CreateQuery("from Parent order by Name desc")
				.SetMaxResults(2)
				.List<Parent>();
	Assert.Equal("foo", parents[0].Name); //Fails expected "foo" was "aaa"
	Assert.Equal("bar", parents[1].Name); // Fails expected "bar" was "foo"
}

I was a bit puzzled at first, these sort of queries in nHibernate is pretty well tested and as i said i had not changed anything related to this, but to be sure i quickly reverted my changes and ran the tests again. And it still failed... Then i suddenly realised what was wrong and why this test suddenly failed. Take a moment and give me your guess on why... 

Yep, you guessed it. My new database running the tests were created using danish collation for sorting and in denmark aa is the same as the danish charecter å which is last in the alphabeth.

I found myself trying to fix a bug in the nHibernate source today.With nHibernate its a pleasure to have a lot of unit tests to make sure you (hopefully) haven't broken anything with your changes. I did what i always do, checked out the nHibernate trunk ran all the tests and no failures. Then i messed around with the source made some changes and wanted to make sure all tests still passed. However in the middle of my fiddling i had dropped the nHibernate database used for unittests and recreated it, but that shouldn't be a problem. nHibernate creates tables needed during its unit testing so all is good.

Then a test failed, and this test had nothing to do with the things i worked on, so i went to investigate the failing testcase called NHibernate.Test.SubselectFetchTest.SubselectFetchFixture.SubselectFetchWithLimit the testcase tries to fetch 2 rows from the database out of tree added and do various asserts on their children to check that collection fetching using the subselect fetch strategy is working. The assertion that failed was that a wrong number of child elements were on one of the parents, and a little investigation showed that the 2 rows returned was not the ones the test expected. To reproduce the error a test like this could be written:

[Test]
public void WrongElementReturnedFromLimitQuery()
{
	//Save three objects to the database with different names
	ISession s = OpenSession();
	Parent p1 = new Parent("foo");
	Parent p2 = new Parent("bar");
	Parent p3 = new Parent("aaa");
	s.Save(p1);
	s.Save(p2);
	s.Save(p3);

	s.Flush();

	IList<Parent> parents = s.CreateQuery("from Parent order by Name desc")
				.SetMaxResults(2)
				.List<Parent>();
	Assert.Equal("foo", parents[0].Name); //Fails expected "foo" was "aaa"
	Assert.Equal("bar", parents[1].Name); // Fails expected "bar" was "foo"
}

I was a bit puzzled at first, these sort of queries in nHibernate is pretty well tested and as i said i had not changed anything related to this, but to be sure i quickly reverted my changes and ran the tests again. And it still failed... Then i suddenly realised what was wrong and why this test suddenly failed. Take a moment and give me your guess on why... 

Yep, you guessed it. My new database running the tests were created using danish collation for sorting and in denmark aa is the same as the danish charecter å which is last in the alphabeth.

Cool stuff

Many experts agree that a good architecture is significantly more important that a fancy new storage bin. It is kind of like asking if giving a carpenter a supply organizer will make a better carpenter. If the carpenter already has the discipline to organ

guide to the nHibernate ORM tool