I didn't took a look at the implementation yet. PHP is caching filesystem infos AFAIK.
Can't we use these file informations as part of the key cache to compute md5 ? So their will be no more need to invalidate, it will invalidate by itself, or by calling (for hard-writting apps) clearstatcache() ? Cheers, Before Printing, Think about Your Environmental Responsibility! Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale! On Tue, Aug 17, 2010 at 3:32 PM, Tom Boutell <[email protected]> wrote: > Daniel, this almost works and I got pretty excited thinking about > it... but there's a tragic flaw. > > On the first page access you slurp up all the CSS files, minify them, > md5 that and create a cache file. Fine. > > On the second page access you... can't point to the cache file without > first doing all of that again (everything except actually writing the > file) just to figure out what the filename is. (: > > Opening all of the files, slurping them in and md5'ing them on every > page access is overhead we do not want. So it makes more sense to have > a cache key. > > On Aug 16, 9:13 am, Daniel Lohse <[email protected]> wrote: > > Sorry for being a bit slow today: why would we need cache invalidation? > If the filename of the compacted file(s) is a hash generated from the > contents of the file then after one file changes and the scripts/stylesheets > are re-generated the filename changes. The browser then should just request > the file because it doesn't about that file yet (filename is not the same). > > > > Am I missing something here? > > > > Cheers, Daniel > > > > Sent from my iPad > > > > On Aug 16, 2010, at 2:59 PM, Tom Boutell <[email protected]> wrote: > > > > > You're right, we do need cache invalidation. I just came up with a > > > clean way to do it without tweaking app.yml settings, adding a table > > > or making glob() calls: just use a file in the asset-cache folder to > > > hold the current cache key. The OS should cache reads from that file > > > extremely well. > > > > > It may even be possible to avoid the filesystem hit by writing it as a > > > PHP file in cache/frontend/prod/config that just calls > > > sfConfig::set(). Then with any luck it would be autoloaded and even > > > cached by APC until its modification date changes just like an app.yml > > > setting would. But plain old file_get_contents() calls to a simple > > > file with an asset cache version number in it would also get cached > > > nicely by the operating system so it might be overkill to try to wedge > > > it into Symfony's cache. > > > > > On Aug 15, 11:44 am, pghoratiu <[email protected]> wrote: > > >>> It might be worthwhile to take things a step further by versioning > > >>> them in the URL so that they can be given an infinite cache > expiration > > >>> date, although this requires a database hit or perhaps a glob call > > >>> when outputting the pages that contain them. The code is a big step > > >>> forward as-is if you are using unminimized, uncombined CSS and JS and > > >>> has no negative impact on your existing caching issues, but we'll > > >>> think about next steps. > > > > >> ==== > > >> I think think it's important to add cache invalidation as well. My > > >> suggestion is to append another key > > >> to app.yml to have a cache key that can be updated manually and append > > >> that key too the minified resource > > >> file: > > >> all: > > >> a: > > >> ver:1 > > >> css/main.css?ver=1 > > >> This way css and js pages can be cached indefinitely on the client > > >> side without having problems when manually > > >> updating the css or js files. > > > > >> gabriel > > > > > -- > > > If you want to report a vulnerability issue on symfony, please send it > to security at symfony-project.com > > > > > You received this message because you are subscribed to the Google > > > Groups "symfony users" group. > > > To post to this group, send email to [email protected] > > > To unsubscribe from this group, send email to > > > [email protected]<symfony-users%[email protected]> > > > For more options, visit this group at > > >http://groups.google.com/group/symfony-users?hl=en > > > > > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<symfony-users%[email protected]> > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
