This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Right now LightSpeed enables persistent caching of individual entities by their id. I've just started performance tuning an application and am finding this a great feature. Have you considered enhancing LightSpeed caching to cache the results of a select of an entire table, and then return those cached results for subsequent selects of the entire table? I would find this useful because my application has many static look up tables that are bound to the UI. I'd like queries that get all entries to hit the cache rather than having to make a query to the database. |
|
|
|
|
If we do this, will you upgrade to LightSpeed 3? *grin* Seriously, that's a nice idea. I'll see what I can do. |
|
|
|
|
There's a first cut in the latest nightly. CachedAttribute now has a CacheFindAllResult property. If set to true, then when you do a "find all" query (a Find with no query expression), the result of that query is cached, and subsequent "find all" queries will just return that same list. (The cache is invalidated if you add or remove an entity of the cached type.) Note that "find with query" queries (e.g. Penguins.Where(p => p.Age > 10)) will still hit the database. The entity instances will be got from the cache, but we have to hit the database to find out which instances match: we don't run the predicate over the in-memory list. CachedAttribute.CacheFindAllResult isn't yet supported in the designer so you will need to apply CachedAttribute manually through a partial class. We will add designer support if you find the feature useful but we'd like to your feedback and bug reports first! |
|
|
|
|
I can't upgrade to LS3 right this moment on my large work project but I'll test it out in my at home project using LS3 soonist. How have you handled ordering? Are there different caches for different orders or does the cache only get hit when no order is applied to the query? |
|
|
|
|
Erm... I haven't handled ordering. That would be a bug then. Thinking about it you can probably also fool it with paging. So that would be another bug then. I'll try to get these fixed in tonight's nightly, but the solution will be "we only cache when there is no order or paging or anything like that." Is this still useful for you? |
|
|
|
|
:P I think it would still be useful if caching is only skipped when an explicit order or paging is given, but it still works when there is a default entity "Order By" (and obviously if the explicit order happens to by the default). My lookups all have a Name property and I set that as the default entity order. For more one off scenarios people can always ToList() the result and then order client side. |
|
|
|
|
It will still work when there is a default entity "order by." However if an explicit order is given then that will cause caching to be skipped: we will not check if the explicit order happens to match the default one. |
|
|
|
|
Appears to work although I don't see any logs when a FindAll result is set or gotten from the cache. |
|
|
|
|
Should be addressed in the next nightly build. |
|
|
|
|
Logging now works. I'm only caching static tables so I haven't got entities being added and removed (I'm guessing that invalidates the all results cache for a table, hopefully with logging :-P) but it all works from my limited perspective. Are you going to be adding designer support? |
|
|
|
