Hi,

I thought I might post this and check whether anyone else can reproduce this issue. Take any Linq query (that returns an IQueryable) and append a Take(0), do you get 0 results? I have tried it on a few queries and I always get the full result set back. I suppose you are wondering why anyone would want to take 0 results. For a start I just stumbled across this, I was curious and wanted to confirm that 0 results are returned. However, I do see a potential real world problem where the take parameter is dynamic, in which case it might actually evaluate to 0.

LLBLGEN Version: 2.6 Final (April 15th, 2009) Runtime library version: 2.6.9.511 Database Engine: SQL Server 2005

I am using the default templates without any changes.

An example of a query that produces this weird result is:

            LinqMetaData context = new LinqMetaData();

            var data = from c in context.Equipment
                       select c;

            var result = data.Take(0).AsEnumerable();

Any ideas? Is this a bug or am I overlooking something fundamental?

Good catch! In LLBLGen Pro, specifying 0 for the max limiter results in all rows, as LLBLGen Pro has no system build in to return 0 rows from a query. We pass the parameter of Take() as that max limiter so specifying 0 will indeed return all rows.

I'm not sure how to fix this properly, as we don't have a mechanism to return 0 rows. I also don't think throwing an exception is useful, as with dynamic input it might result in an exception which was unexpected.

We'll look into it.

Great, thanks. Thought that perhaps someone had raised this before but searching for "Take" doesn't really work so well if you considers it's in the list of ignored search terms

I think you should throw an exception in the case where a negative parameter is passed, right now passing a negative value induces the same behavior as described above.

Also, the same issue is reflected in the usage of the TakePage method. If 0 is passed as the page size all results are returned.

Rohland wrote:

Also, the same issue is reflected in the usage of the TakePage method. If 0 is passed as the page size all results are returned.

That's expected, TakePage is our own extension method for paging, so it has the same characteristics as our normal API, where you pass in 0 for page no/size if you don't want to have paging.

If we throw an exception, it's a breaking change (as currently applications work properly with input '0') and we decided not to do that. The problem is that Take(0) should now result in 0 rows, which is hard to do, as it has to append a where clause which results in false and always limits the query to 0 rows.

Therefore we leave the code as-is. As this is a case which not a lot of people will run into (if at all, I don't see how dynamic usage of Take() would still cause 0 to be passed in, using Take is always a deliberate thing), we don't see this as something to do the effort for to make sure the query results in 0 rows, as that's as said above, very difficult, if not impossble to do in all cases.

Thanks for reporting though