The server side cache is very powerful and provides ways to cache what it refers as IDEFQUERY or item definition single get queries.
Item definitions could be marked for caching, via a cacheSince attribute which preferably would be equal to the request limiter since attribute; another option is cacheAll to literally cache everything for that item.
Add event listeners for records added, records removed, and records edited (similar to #10 so #10 should be done) for a none domain, so that is just inform for these changes on a table level to keep them updated in each cluster level cache by the cluster manager.
Every record should then register and store each of its respective IDEFQUERY as well, similar to how the cache worker does it in the client side.
The records stored in the cache should be different than the standard records and during the cache and indexing event we should retrieve both last_modified and created_at in order to be able to keep these records clean as they age, because we don't want a forever growing cache, however we would only clean it as we need to change it.
This will be the job of the cluster manager to mantain these records, and even download and register them; each extended node will have nothing to do with this.
However the appData.cache will then need a search method so that it can then use those cached records to perform its search and will use the local search functions in order to do the matching.
After filtering is done using the local search functions then we would have to use local ordering as well, these are the same functons used in the client side for the cache worker.
Pitfalls.
- No support for full text search, this means that if detected will have to fallback to postgresql; probably by noticing that the local search function is null/undefined for one of the search fields; this same flaw exists on the client side; however it might also be possible to just pass the tsquery to postgresql to check whether it matches true or false since we are on the server side.
Unsure whether this will be implemented at all because postgresql is fast as it is, and searches are not very common, so it doesn't have a lot of value unless the system is so big that searches are constantly performed and the database needs a relief.
The server side cache is very powerful and provides ways to cache what it refers as IDEFQUERY or item definition single get queries.
Item definitions could be marked for caching, via a cacheSince attribute which preferably would be equal to the request limiter since attribute; another option is cacheAll to literally cache everything for that item.
Add event listeners for records added, records removed, and records edited (similar to #10 so #10 should be done) for a none domain, so that is just inform for these changes on a table level to keep them updated in each cluster level cache by the cluster manager.
Every record should then register and store each of its respective IDEFQUERY as well, similar to how the cache worker does it in the client side.
The records stored in the cache should be different than the standard records and during the cache and indexing event we should retrieve both last_modified and created_at in order to be able to keep these records clean as they age, because we don't want a forever growing cache, however we would only clean it as we need to change it.
This will be the job of the cluster manager to mantain these records, and even download and register them; each extended node will have nothing to do with this.
However the appData.cache will then need a search method so that it can then use those cached records to perform its search and will use the local search functions in order to do the matching.
After filtering is done using the local search functions then we would have to use local ordering as well, these are the same functons used in the client side for the cache worker.
Pitfalls.
Unsure whether this will be implemented at all because postgresql is fast as it is, and searches are not very common, so it doesn't have a lot of value unless the system is so big that searches are constantly performed and the database needs a relief.