Hi there!

I am currently fiddling around with resultset caching functionality, it appears that when a query does not return any rows, nothing is being cached.

This results in the following behaviour: When fetching a query with, say, 5 prefetch paths, 6 queries are executed. If 2 of those prefetches do not return any rows, 4 resultsets are being cached. When fetching the same query again within the specified expiration duration, the 2 prefetch queries that did not return any rows will execute again. This may result in an inconsistent entity graph in memory.

Is this behaviour by design? What i need is actually the entire result to be cached, also when the result is 0 rows. I cannot change this behaviour by implementing my own ResultsetCache.

• LLBLGen Pro v4.02 Final
• SQL Server

Amyyon wrote:

Hi there!

I am currently fiddling around with resultset caching functionality, it appears that when a query does not return any rows, nothing is being cached.

This results in the following behaviour: When fetching a query with, say, 5 prefetch paths, 6 queries are executed. If 2 of those prefetches do not return any rows, 4 resultsets are being cached. When fetching the same query again within the specified expiration duration, the 2 prefetch queries that did not return any rows will execute again. This may result in an inconsistent entity graph in memory.

Is this behaviour by design?

Hmm. We didn't anticipate this, to be honest, and I see your point, the graph should be seen as one unit at one point in time.

What i need is actually the entire result to be cached, also when the result is 0 rows. I cannot change this behaviour by implementing my own ResultsetCache.

• LLBLGen Pro v4.02 Final
• SQL Server

We'll look into it, what we can do about this. Keep in mind that 4.2 doesn't receive any new features nor fixes. But perhaps there's a way to override some method to make this happen. We'll get back to you.

Otis wrote:

We'll look into it, what we can do about this. Keep in mind that 4.2 doesn't receive any new features nor fixes. But perhaps there's a way to override some method to make this happen. We'll get back to you.

Ok, thanks for lookin into it!

It's currently not possible to change this behavior by a simple method override: the row caching occurs after a row has been read and processed. So if no row is present, the row caching won't happen (as the set is empty) and nothing is cached. We have to make architectural changes for this, so we've filed a workitem to change this behavior in a future version.

Thanks again, for now i will use some sort of 2nd level caching that caches entire entity objects.

Implemented in LLBLGen Pro v5.6