Ayende @ Rahien

Pawel Lesnikowski commented on Find the differences: The optimization that changed behavior

Mon, 21 Sep 2009 06:20:50 GMT

As far as I remember IN query has limits at least in Oracle database.

gunteman commented on Find the differences: The optimization that changed behavior

Sun, 20 Sep 2009 12:48:02 GMT

It's important to at least have the option to use the IN query version, especially if the query should be decorated from other sources, such as Rhino.Security

Paul Hatcher commented on Find the differences: The optimization that changed behavior

Thu, 17 Sep 2009 11:09:42 GMT

Is this still true, I applied a patch (see [http://nhjira.koah.net/browse/NHSR-17](http://nhjira.koah.net/browse/NHSR-17)) that addressed at least one use case of this.

Chris Smith commented on Find the differences: The optimization that changed behavior

Thu, 17 Sep 2009 10:54:04 GMT

I can see a big stinking NullReferenceException about to happen though :)

Johannes Gustafsson commented on Find the differences: The optimization that changed behavior

Thu, 17 Sep 2009 06:51:17 GMT

I Guess one solution could be some kind of this? public IList typeof(T).IsAssignableFrom(Assembly.GetExecutingAssembly().GetType(x.className))).Select(x=>x.Id))) .List(); } >

Howard Pinsley commented on Find the differences: The optimization that changed behavior

Wed, 16 Sep 2009 15:34:39 GMT

Expanding on what Johannes mentioned, it seems like you can actually get an non-matching item of type T that exits with an id that was returned by the Lucene search for an entirely different class?

Ayende Rahien commented on Find the differences: The optimization that changed behavior

Wed, 16 Sep 2009 09:11:54 GMT

Dmitriy, 1 isn't true, the DoLuceneQuery doesn't hit the DB.

Ayende Rahien commented on Find the differences: The optimization that changed behavior

Wed, 16 Sep 2009 09:03:00 GMT

Mogens, Yep :-)

Ayende Rahien commented on Find the differences: The optimization that changed behavior

Wed, 16 Sep 2009 09:02:22 GMT

Johannes, Yep, that is a big change in behavior.

Ayende Rahien commented on Find the differences: The optimization that changed behavior

Wed, 16 Sep 2009 09:00:29 GMT

Configurator, Sort order is one such problem, yes.

Mogens Heller Grabe commented on Find the differences: The optimization that changed behavior

Wed, 16 Sep 2009 06:04:06 GMT

One difference is that the first version will take advantage of the 1st level cache and the 2nd level entity cache if it is enabled. The second version will always go to the database.

Johannes Gustafsson commented on Find the differences: The optimization that changed behavior

Wed, 16 Sep 2009 06:01:00 GMT

The first query uses idAndClass.className to get the entity. If it is possible for idAndClass.className to be something else than T, then the second query could return an entirely different entity. On the other hand, the first query would throw in this case.

Bunter commented on Find the differences: The optimization that changed behavior

Wed, 16 Sep 2009 05:48:02 GMT

Will the second one fail if no rows are returned by lucenesearch?

Markus Zywitza commented on Find the differences: The optimization that changed behavior

Wed, 16 Sep 2009 05:29:31 GMT

1) Original code loads proxies, the optimized code loads the full objects. 2) The optimized code loads only T while the original code loads T and subclasses of T

Dmitry commented on Find the differences: The optimization that changed behavior

Wed, 16 Sep 2009 05:00:01 GMT

The query in the second example would always hit the database but it would only be done once. You might hit a 2100 parameter limit if it uses the IN clause. The first example can take advantage of the identity map.

Dmitriy Nagirnyak commented on Find the differences: The optimization that changed behavior

Wed, 16 Sep 2009 04:49:25 GMT

I think 3 major differences are: 1. The 2nd case executes (in theory) 2 SQL queries. One to return Class+Id, the 2nd to return the actual list (probably using SELECT... FROM... WHERE id in (...). With all the pros/cons. 2. The 2nd case ignores the NH 2nd level cache. 3. The 2nd approach ignores the class thus you cannot use search with inheritance.

configurator commented on Find the differences: The optimization that changed behavior

Wed, 16 Sep 2009 04:34:03 GMT

Is it possible that DoLuceneSearch can return the same row multiple times? Also, this would do this in a different sort order if I'm not mistaken. (That is, if sort order in even an issue at that level which I assume it is) Note: I don't use NHibernate, and I have no idea what Lucene is, so this is nothing more than an educated guess.