2

How can I disable cache in the cli enviroment?

Reason being, the system user that executes the script is not allowed to write to the cache directory, thus the script is unable to execute.

In my application.ini I have

[production]

resources.cachemanager.database.frontend.name = Core
resources.cachemanager.database.frontend.customFrontendNaming = false
resources.cachemanager.database.frontend.options.lifetime = 7200
resources.cachemanager.database.frontend.options.automatic_serialization = true
resources.cachemanager.database.backend.name = File
resources.cachemanager.database.backend.customBackendNaming = false
resources.cachemanager.database.backend.options.cache_dir = HTTPDOCS_PATH "/data/cache/database"
resources.cachemanager.database.frontendBackendAutoload = false

[cli : production]

*<]:-)

mercator
  • 28,290
  • 8
  • 63
  • 72
Phliplip
  • 3,582
  • 2
  • 25
  • 42

2 Answers2

4

Try

resources.cachemanager.database.frontend.options.caching = false

See the API and the ZF Reference Guide for the $_options property in Zend_Cache_Core

Gordon
  • 312,688
  • 75
  • 539
  • 559
  • 1
    resources.cachemanager.database.frontend.options.caching = false resources.cachemanager.database.backend.options.cache_dir = "/tmp" Solved my problem - Thank you! – Phliplip Jan 13 '11 at 11:54
1

Like you, I see no obvious way to disable a plugin in a config section that was registered in a parent section. It would be cool if Zend_Config_Ini allowed multiple inheritance, kind of like how an HTML element can multiple CSS classes in the class attribute. (Does it? I'm guessing not). Then you could put the plugin registration into one section [myplugsection], allow [production] to extend [myplug] while [cli] does not, kind of like how Doctrine has actAs templates and beahviors.

The next best thing might be to create a section called something like [core]containing most of what you now habe in [production]. Both [production] and [cli] could extend [core], but [production] would register the plugin while [cli] would not.

Of course, an alternative would be to could move the plugin registration into Bootstrap where you have finer control of the plugin registration. In particular, you can call $front->unregisterPlugin(), where $front is the FrontController.

Just thinking out loud...

Cheers!

David Weinraub
  • 14,144
  • 4
  • 42
  • 64
  • D'oh! Just realized you are talking about resources not plugins. In principle, though, the inheritance scheme I outlined - using `[core]` as commom parent section to `[cli]` and `[production]` should work for any content you put in a section, including `resources.*`. – David Weinraub Jan 14 '11 at 08:36