Ayende @ Rahien

Ayende Rahien commented on NH Prof Alerts: Unbounded result set

Mon, 05 Jan 2009 19:57:56 GMT

The question is what you are trying to optimize. If you are trying to optimize throughput of a single action, you might be better of with a single large process. Even then, a streaming approach would work much better than any other. If you have several processes running at the same time, the batching approach is far more performant, because you don't have a single big process sucking out all the system resources. Even if you have lot of memory, and lot of bandwidth, we have more data than that.

Ross Beehler commented on NH Prof Alerts: Unbounded result set

Mon, 05 Jan 2009 17:18:53 GMT

Can you list the factors that may lead you to use 'batches' when dealing with a large set of entities you know you will all have to process? In our specific scenario, I have a little tougher time seeing it, as from a database server perspective, we've noticed that the sum of all "page" queries is more expensive than a single query to get all data. On our app server(s), we're using 64 bit, so running out of memory is less of a concern. Also, there's usually a pretty big pipe between the database and the application server. Anything else I'm not considering?

Ayende Rahien commented on NH Prof Alerts: Unbounded result set

Sun, 04 Jan 2009 01:34:03 GMT

Steve, No, it wouldn't be. Because when you enter paging into the mix, you also start handling things in batches. Sure, if you blindly slap a limit clause on anything, this is a problem, but you shouldn't do that anyway.,

Steve Wagner commented on NH Prof Alerts: Unbounded result set

Fri, 02 Jan 2009 17:41:23 GMT

Could a limit on all querys not also be a time bomb? If i assume a table has max 25 record because it currently have only 10. But after 3 years someone which dose not know of this limitation adds 30 i have also an application which dose not work correctly. Wouldn't it better if i check the resultset count and send warnings to the developers when a border is reached?

configurator commented on NH Prof Alerts: Unbounded result set

Mon, 29 Dec 2008 22:33:33 GMT

If this is a common scenario, shouldn't there be an overload for CreateFilter(object) that assumes the query is String.Empty?

Ayende Rahien commented on NH Prof Alerts: Unbounded result set

Mon, 29 Dec 2008 14:54:18 GMT

Sjaaky, This is actually something that you would want to use the Stateless Session for.

Sjaaky commented on NH Prof Alerts: Unbounded result set

Mon, 29 Dec 2008 14:50:29 GMT

Sometimes we need to update all records in one table of de database. We wanted to keep the ISession small, since large ISession's seems to be a performance killer. So I wrote this function: public static IEnumerable

Ayende Rahien commented on NH Prof Alerts: Unbounded result set

Mon, 29 Dec 2008 12:33:51 GMT

Udi, If you want to read the full list, you need to explicitly acknowledge that, although I think that even when you need the full list, you should try to process that in batches rather than the full list (which may be hundreds of thousands of items). I am not sure that I understand what you mean about NH Prof story for OLTP

Udi Dahan commented on NH Prof Alerts: Unbounded result set

Mon, 29 Dec 2008 10:03:19 GMT

Yet there are OLTP scenarios (not showing data to a user) where you actually want the full list. I'm not saying that that code could not benefit, performance-wise, from being rewritten in a more denormalized fashion, or possibly using straight SQL, but that domain models will continue to have regular "parent.children.etc.etc.so_forth". What is the NH Prof story for OLTP?