$cacheManager->clearCache(array (
"{$resource->context_key}/resources/".$_POST['parent'].".cache.php"
),
array(
'objects' => '*',
'publishing' => true
)
);
☆ A M B ☆
MODX Staff
$modx->cacheManager->clearCache(array($resource->getCacheKey() . '.cache.php'));
IOW, a snippet to create a menu will not be aware of a change to the alias, or any new documents that may have been added without clearing the context cache.
MODX Staff
IMO, collaborative web applications like you describe should be created using a single Resource serving as a view into the highly dynamic content being posted. Any navigation for these posts would similarly be dynamic and not be related to the main web site cache anyway. However, as an alternative to avoid creating a custom web application and data structure for supporting it, you can partition the collaborative portion of the site into a separate context so that posting changes to/adding Resources only affects that context’s cache.
IOW, a snippet to create a menu will not be aware of a change to the alias, or any new documents that may have been added without clearing the context cache.
Exactly.
practically, this means that whenever a user post content (resource) in HIS profile, the whole site’s cache needs to be purged in order to refresh the map (clearing the context cache).
In a collaborative web site, where posting is what people do.. this makes no sense.
If you don’t clear the other pages, they will not be aware of the changes to the URL structure of the site; same problem regarding navigation components. That said, we could provide this option when creating/editing a Resource, but you’d have to be aware that any navigation component would have to be uncached.
Question - clearing the specific page cache + context.cache vs. clear all the cache. makes sense? as then only the resource map would be rebuilt, but the other pages will stay cached.
AFAIK, this shouldn’t lead to any cache inconsistency, and looks like it’ll save some CPU (again - just imagine this site is about posting..)
In the first phase (500 users * 5-10 posts each, mild activity) - i doubt if the (lack of) cache would present a problem, but it would be nice to be able to selectively refresh a fragment of the context.cache (I am sure you agree it totally makes sense).
Working with graph objects is actually less heavy than the alternative; these use simple joins and can greatly reduce database load when used appropriately. Combined with lazy loading techniques, you can also reduce memory consumption as appropriate (i.e. if you are only using a few fields from an object graph).
(un)related - I am now examining getCacheManager() for my custom snippets to minimize db queries.
Working with a complex structure (multiple tables define a user) and xpdo’s Graph objects is heavy! seems like if I brake some fragments and use the above to create my own custom cache files, mainly to cache member details - i could minimize the need to use graph objects (getObjectGraph/getCollectionGraph).
As an interesting built-in alternative -
I saw this "xPDO Object and Database Result Set Caching" here: http://svn.modxcms.com/docs/display/revolution/Caching
and "Enable database cahce (cache_db)" in the "system settings"
and this: xPDOMemCache
and the $cacheFlag in xpdo’s Graph methods (I would put a BIG number here?)
and ofcourse this: xpdo’s fromCache method.
As far as I understand - these can assist the performance (in my case) even more the above (post caching).
I’m still not 100% clear on how it all interacts, but that should be resolved in the next days.
Psuedo-code or any guideline would be greatly appriciated.
Any specific reason why cache_db is disabled by default?
(seems like this is a hidden-power waiting to be explored under revo)
IMO, collaborative web applications like you describe should be created using a single Resource serving as a view into the highly dynamic content being posted. Any navigation for these posts would similarly be dynamic and not be related to the main web site cache anyway.
If you don’t clear the other pages, they will not be aware of the changes to the URL structure of the site; same problem regarding navigation components. That said, we could provide this option when creating/editing a Resource, but you’d have to be aware that any navigation component would have to be uncached.
cache_dbLooks interesting, I want to test this, but i got this error, once I enabled this setting, I lost manager + all front-end pages:
Fatal error: Cannot access protected property xPDOQuery_mysql::$sql in C:\xampp\htdocs_81\core\xpdo\xpdo.class.php on line 1460
for other as reference - you can recover from this kind of event by: a. changing the setting in the db: UPDATE modx_system_settings SET `value`='0' WHERE `key`='cache_db' b. delete this file: core/cache/config.cache.php
☆ A M B ☆
) is extremely fast and straight forward!
MODX Staff
This is fixed in branches/2.0 @ revision 6235; it was an error in xPDO 2.0 since the php 5 only changes were introduced. Let me know if you find any other problems with the cache_db functionality.
@OpenGeek, I would be grateful for an answer to my post #6
(especially regarding enabling db_cache..)
Now that it’s fixed, the cache_db functionality should work fine. And you don’t need to specify the $cacheFlag; this can be controlled system wide using the cache_db_expires system setting (which by default is 0, which means it never expires unless the database row is changed).
from the various caching methods available, which would you recommend?
How does xpdo’s getObjectGraph $cacheFlag param play along the db caching technics you mentioned? is it dependent on db_cache or unrelated? do I need to explicitly use fromCache?