Re: [fw-general] ZF 1.8 and Performance Guide (using find/sed to remove require once calls)
If you want to remove the disk as a bottleneck then get apc going and
turn apc.stat=0. This will cache your scripts in memory and never go
back to disk until you clear the cache (and/or restart apache).
- Tony
On May 12, 2009, at 12:40 AM, Laurens0619 wrote:
Hi Matthew,
I am trying to gain performance because our server (ibm as/400) is
really
slow with disk access.
I've tried the solution from the manual by removing the require_once
statements and use the autoloader.
I get the same error, just blank pages. I have error reporting on so
I can't
find the problem.
Autoloader is on by using the new architecture with zend_application.
Thanks in advance,
Laurens
Matthew Weier O'Phinney-3 wrote:
-- j5 young.ke...@gmail.com wrote
(on Friday, 01 May 2009, 02:33 PM -0700):
I was tinkering with ZF 1.8 and the performance guide.
Specifically:
C.2.2.1. Strip require_once calls with find and sed.
The sed/find commands here have changed I noticed. When I run
these new
commands I get the following error:
-bash: syntax error near unexpected token `('
I took a look at the commands again and I thought I found a
missing '
error
I've fixed this on trunk and the 1.8 release branch now, and the
changes
will show when we release 1.8.1. Thanks for the report!
so I tried the revised commands:
find . -name '*.php' -not -wholename '*/Loader/Autoloader.php' -
print0 |
\
xargs -0 sed --regexp-extended --in-place 's/(require_once)/\/\/
\1/g'
(I added a ' after Autoloader.php).
That looked like it worked. But now when I browse to my website, I
get a
blank page.
I am not sure if what I did fixed anything or what..
Anyone have any suggestions?
Do you have display_errors on? If not, turn it on to see if any
errors
are being reported.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
--
View this message in context:
http://www.nabble.com/ZF-1.8-and-Performance-Guide-%28using-find-sed-to-remove-require-once-calls%29-tp23340034p23497684.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend Framework team reorganization
Just wanted to say Congrats Matthew! The promotion is well deserved. Keep up the hard work :) - Tony
Re: [fw-general] Smarty Poll Question
Sure, I won't disagree with any of your points, but I'm choosing to not assume anything. That's why we benchmark. - Tony On 9/29/2008 1:41 AM, Karol Grecki wrote: Rendering views is usually not a bottleneck in any application. Even if Smarty is slow, it should still account for a just a fraction of total request time. I'm not big on Smarty so normally I wouldn't hold you back, but I think your intentions are misplaced. Performance is the last thing I would worry about in this case. Features and simplicity, that's a different story. Karol Tony Ford wrote: Well I'm obviously not going to refactor anything if there is no noticeable performance gain. Hence, my whole entire point of benchmarking in the first place. Are you asserting its a waste of time to see if zend view is faster than smarty? I have my doubts about how well smarty compiles templates into php. For more complicated templates there could be a decent difference between the php smarty produces and what a seasoned web developer can write using zend view. And let's not dismiss a lot of the nice feature benefits of zend view over smarty, especially some of the integration with other zend framework components, dojo, and the active continued development of zend view. You have to be honest that feature wise, in the long term, zend view is more attractive than smarty. - Tony
Re: [fw-general] Smarty Poll Question
We still use smarty for basic legacy reasons. I'm interested in running some benchmarks between zend view and smarty. If there is a significant performance increase I'll consider refactoring all of our views over time. I plan to do our own benchmarking in the next couple of months, so I'll share that later. Anyone else done any benchmarking? - Tony On 9/24/2008 1:23 PM, Karol Grecki wrote: Used it few years ago when css adoption was poor and there were no decent mvc frameworks. Nowadays it's no longer necessary. It's also old php4 code that I'd rather stay away from. Karol Garrison Locke wrote: I know this usually starts a big war, but I was just curious about how many people out there are using Smarty and to what extent you're using it? If you're not using it, why did you decide to not use it? If you are, why? Also, if you're using it, how big or small are the projects? Just personal things or like giant things with tens of thousands of users. Thanks! Garrison
Re: [fw-general] SVN Repository Reorganization
I just submitted a final proposal of sorts, based on all feedback to date. I quite like the way it turned out and overall I think its a great compromise and is based on best practices of other large open source project repositories like the apache foundation and php itself. - Tony On 5/16/2008 8:39 AM, Darby Felton wrote: Hello again, So far I've seen some very helpful feedback on the proposed SVN repository reorganization. Thank you to everyone who has posted so far! :) For those of you that haven't commented yet, however, please review and post your thoughts. I'm thinking that we'll stop collecting feedback on Monday, so please post your feedback by the end of Monday if at all possible. Thanks again! :) Best regards, Darby Darby Felton wrote: Hi all, In order to prepare the framework SVN repository for accommodating the upcoming distinction between standard and extras components, and to consolidate the currently separate laboratory repository, we have prepared a proposed SVN structure for your review. And yes, this means you. :) We are particularly interested in receiving feedback from both ZF users and ZF developers regarding this reorganization, and you can help by taking a look and commenting on the following wiki page: http://framework.zend.com/wiki/x/sAEa Please let us know if you see any glaring oversights or even if you just see a little room for improvement - your feedback would be sincerely appreciated. If you don't have wiki commenting privileges, please send an e-mail (from the address associated with your JIRA/Confluence account) to [EMAIL PROTECTED] and ask for posting privileges. :) Thanks in advance for your feedback! Best regards, Darby
Re: [fw-general] Using Zend_Config / Changing a module behaviour
We do it differently, and better in my opinion. In your bootstrap:
1) Figure out which type of env
2) Load appropriate config
3) Set the config object in the registry
In your controller super class be sure to set a protected member
$_config, which you can get from the registry during construction.
Now $this-_config is always available in your controllers. You can do
the same for your model super class too.
We do stuff with ini files and sections, we also merge several configs
because the app is layered in a specific way for our stuff, and we even
allow loading custom configs so developers can setup whatever type of
config they want on their own local machines, but that's the basics.
BTW, we used to use SetEnv in apache but quickly figured out that it
doesn't help you when you're doing cli php. We run cronjobs written in
php for lots of different stuff and crons need a dev env too. So, we
figured out we could actually use php.ini to set the env, which will
allow us to know the env using php as an apache module OR cli. First set
a directive in your php.ini, like:
app_environment = dev
Then in your bootstrap you can access this with:
get_cfg_var('app_environment')
- Tony
On 12/2/2007 11:33 AM, robert mena wrote:
Hi,
I've adopted ZF as the framework that I am rewriting my modules. One
of the things I'd like to do is have a better way of changing /
defining some of my modules' behaviour.
I am considering using Zend_Config (not sure if .ini o .xml) and have
development, stagging and production config files. When the bootstrap
is called I find out which enviroment I am using and in my __construct
I load the appropriate config file.
Basically I have 3 questions:
a) should I use Zend_Config or is there any better way?
b) which format should I use? ini or xml? The parameters can be
numbers, strings or mixed arrays
c) If I use Zend_Config I am planning something like the snippet
below. Any advice on using it or a smarter way?
.../blog/application/models,views,controllers
.../blog/application/config/devel.xml, stagging.xml production.xml
index.php
...
if(some tests do define the environment as devel)
Zend_Registry::set('ENVIRONMENT','devel')
elseif(some tests do define the environment as stagging)
Zend_Registry::set('ENVIRONMENT','staggingl')
else
Zend_Registry::set('ENVIRONMENT','production')
blog/IndexController.php
class Blog_IndexController
{
function indexAction()
{
... throw an Exception if the environment is not defined...
$blog = new Blog(...,Zend_Registry::get('ENVIRONMENT');
}
}
Blog.php
class Blog
{
function __construct(...,$environment)
{
$config = new
Zend_Config(/path_to_module/config/.$environment..xml) ;
}
}
Thanks.
[fw-general] Zend_Session - problem with illegal session ids, might be a larger general php issue
Recently our company started scanning a new ZF based site we just
launched. It's some sort of security scanner that checks for things
like sql injection, XSS, etc. Anyway, it presented a problem with
sessions that I've never encountered before. This scanner, for whatever
reason, resets all cookie values to some weird uri. So now, instead of
the session cookie looking like:
e3200af3b875e6c78e916e49c6acc315
it looks like:
http://example.com/some.html
The uri obviously has characters like ':' and '/', which are of course
illegal characters for a session id. The problem? First of all, this
throws a Zend_Session_Exception, example:
[21-Aug-2007 15:05:50] PHP Fatal error: Uncaught exception
'Zend_Session_Exception' with message 'Zend_Session::start() -
session_start(): The session id contains illegal characters, valid
characters are a-z, A-Z, 0-9 and '-,'' in
/z/applib/lib/Zend/Session.php:379
Stack trace:
#0 /z/applib/app/bootstrap.php(72): Zend_Session::start()
#1 /z/www/obscurity_network/app/networkbootstrap.php(53):
require('/z/applib/app/b...')
#2 /z/www/obscurity.obscurity.com/index.php(9):
require('/z/www/obscurity_net...')
#3 {main}
thrown in /z/applib/lib/Zend/Session.php on line 379
Secondly though, the reason this happens in the first place, php
actually throws a warning when a session id contains illegal
characters. Example:
Warning: session_start() [function.session-start]:
The session id contains illegal characters, valid characters are a-z,
A-Z, 0-9 and '-,' in /obscurity.php on line 88
What do you guys think? In my opinion, the session extension should
gracefully handle this without a warning. Then again, cookies can be
considered user input, therefore should be filtered ... I dunno. At the
very least, something should be added to the Zend_Session start()
method to check the session id before session_start() is called. At
most, a bug report should be filed at php.net to change the behavior of
the warning.
I'm willing to help however I can, but wanted some opinions first.
(BTW, running php 5.2.2)
Regards,
Tony
Re: [fw-general] zend auth session timeout
It doesn't really matter what you set that to if the entire session expires. You need to take a look at these settings: cookie_lifetime gc_maxlifetime If cookie lifetime is set to 0 then any session will expire when all browser windows are closed. If set less than 24 hours, obviously the session cookie will expire as well. gc max lifetime can be a little tricky. The session garbage collector goes out and removes sessions that have not been active for greater than gc max lifetime. Therefore, if gc max lifetime is set less than 24 hours, a session has the potential to be removed from the servers before 24 hours. For instance, let's say gc max life time is set to 4 hours. That means, if I have a period of inactivity for ~ 4 hours (it depends upon how probability and divisor are set), even if I haven't closed my browser, the garbage collector will clean up my session on the server, so my next request will no longer have a valid session. - Tony On 8/23/2007 10:55 AM, Raul Andres Gomez Quijano wrote: // Set Auth Session Expiration to 24 hours // $objSessionNamespace = new Zend_Session_Namespace( 'Zend_Auth' ); $objSessionNamespace-setExpirationSeconds( 86400 ); it isnt working, zend auth session expires early... thanks in advance. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
Re: [fw-general] zend auth session timeout
True, in which case you can use "save_path" when you create the session object and avoid that issue. That is, if you are allowed to use ini_set(), which you'll need to set any of these options. Or, if you have access to the php.ini then you just set them all there. - Tony On 8/23/2007 2:25 PM, Gunter Sammet wrote: As a side not to garbage collection: IIRC, if you are on a shared server or have another app that shares the same session directroy, the application with the shortest lifetime determines it. HTH G. On 8/23/07, Tony Ford [EMAIL PROTECTED] wrote: It doesn't really matter what you set that to if the entire session expires. You need to take a look at these settings: cookie_lifetime gc_maxlifetime If cookie lifetime is set to 0 then any session will expire when all browser windows are closed. If set less than 24 hours, obviously the session cookie will expire as well. gc max lifetime can be a little tricky. The session garbage collector goes out and removes sessions that have not been active for greater than gc max lifetime. Therefore, if gc max lifetime is set less than 24 hours, a session has the potential to be removed from the servers before 24 hours. For instance, let's say gc max life time is set to 4 hours. That means, if I have a period of inactivity for ~ 4 hours (it depends upon how probability and divisor are set), even if I haven't closed my browser, the garbage collector will clean up my session on the server, so my next request will no longer have a valid session. - Tony On 8/23/2007 10:55 AM, Raul Andres Gomez Quijano wrote: // Set Auth Session Expiration to 24 hours // $objSessionNamespace = new Zend_Session_Namespace( 'Zend_Auth' ); $objSessionNamespace-setExpirationSeconds( 86400 ); it isnt working, zend auth session expires early... thanks in advance. -- This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
Re: [fw-general] Major headache trying to tweak or extend Zend_Cache
Thanks for the consideration :)
On 6/9/2007 1:03 AM, Fabien MARTY wrote:
Hi,
I will review for 1.1.0
http://framework.zend.com/issues/browse/ZF-1524
Thanks
2007/6/8, Tony Ford [EMAIL PROTECTED]:
Find attached a patch file for this.
Thanks,
Tony
On 6/7/2007 1:07 PM, Tony Ford wrote:
Zend_Cache seemed very elegant to me at first, until I tried to make a
customization.
I have some apps that will be using memcached for objects. Thing is,
some of my server farms will have multiple sites and networks, all
using the same pool of memcached servers. Of course all the networks
will cache similar named objects, like 'acl' for instance. So, to
avoid namespace trampling, or rather to create namespaces, I thought
it'd be very useful to have cache id prefixes. Now, instead of setting
keys in memecached just called 'obj_name' they'd be
'uniquenetwork_obj_name'. This allows me to have an acl object for
Network1 (network1_acl) and an acl object for network2 (network2_acl).
I could just go ahead and setup a constant and pass it in along with
the ids into every load(), save(), remove(), etc calls, but that seems
like a lot of unnecessary crap. Instead, it makes a lot more sense to
me to create a new backend option for my cache id prefix, then have
each one of those methods concat the prefix on to the front of ids
automatically just before the real memcache calls are made.
So, I went about this, and its a real mess. First of all, all options
are hardcoded into the classes and get explicitly checked at object
instantiation. OK, well, I extended Zend_Cache_Backend_Memcached and
did this:
public function __construct($options = array())
{
// add cache id prefix as an allowed option, default nothing
$this-_options['cache_id_prefix'] = null;
// Call parent constructor
parent::__construct($options);
}
Then each one of those methods now look basically like this:
public function load($id, $doNotTestCacheValidity = false)
{
$id = $this-_options['cache_id_prefix'] . $id;
parent::load($id, $doNotTestCacheValidity);
}
Overall, I didn't think that was too big of a deal, but then I
realized that the backends are hardcoded and checked in Zend_Cache,
just like the options, so I'd have to do the same thing for that.
What's worse though, is only the name of the backend is passed in, and
then class names are created and called with a hardcoded
'Zend_Cache_Backend' . $backend. Now I can't even call my class
something different. Now I'd have to create my class file specifically
in the /Zend/Cache/Backend directory, and call it something like
CustomMemcached.
Anyway, overall Zend_Cache is a very nice component with lots of
options, and I appreciate all of them, its just that its very closed.
Maybe that was the intention, and if so, maybe you would accept a
patch file from me to officially add this feature to the memcache
backend.
Thanks in advance for reading,
Tony
Index: Memcached.php
===
--- Memcached.php (revision 264)
+++ Memcached.php (working copy)
@@ -64,6 +64,9 @@
* = (boolean) compression :
* true if you want to use on-the-fly compression
*
+ * = (string) cache_id_prefix :
+ * prefix for cache ids
+ *
* @var array available options
*/
protected $_options = array(
@@ -72,7 +75,8 @@
'port' = Zend_Cache_Backend_Memcached::DEFAULT_PORT,
'persistent' =
Zend_Cache_Backend_Memcached::DEFAULT_PERSISTENT
)),
-'compression' = false
+'compression' = false,
+'cache_id_prefix' = null
);
/**
@@ -98,6 +102,11 @@
Zend_Cache::throwException('The memcache extension must
be loaded for using this backend !');
}
parent::__construct($options);
+if (isset($this-_options['cache_id_prefix'])) { //
particular case for this option
+if (!preg_match('~^[\w]+$~',
$this-_options['cache_id_prefix'])) {
+Zend_Cache::throwException('Invalid cache_id_prefix
: must use only [a-zA-A0-9_]');
+}
+}
if (isset($this-_options['servers'])) {
$value= $this-_options['servers'];
if (isset($value['host'])) {
@@ -131,7 +140,7 @@
if ($doNotTestCacheValidity) {
$this-_log(Zend_Cache_Backend_Memcached::load() :
\$doNotTestCacheValidity=true is unsupported by the Memcached backend);
}
-$tmp = $this-_memcache-get($id);
+$tmp = $this-_memcache-get($this-_id($id));
if (is_array($tmp)) {
return $tmp[0];
}
@@ -146,7 +155,7 @@
*/
public function test($id)
{
-$tmp = $this-_memcache-get($id);
+$tmp = $this-_memcache-get($this-_id($id));
if (is_array($tmp)) {
return $tmp[1];
}
@@ -173,7 +182,7
[fw-general] Major headache trying to tweak or extend Zend_Cache
Zend_Cache seemed very elegant to me at first, until I tried to make a
customization.
I have some apps that will be using memcached for objects. Thing is,
some of my server farms will have multiple sites and networks, all using
the same pool of memcached servers. Of course all the networks will
cache similar named objects, like 'acl' for instance. So, to avoid
namespace trampling, or rather to create namespaces, I thought it'd be
very useful to have cache id prefixes. Now, instead of setting keys in
memecached just called 'obj_name' they'd be 'uniquenetwork_obj_name'.
This allows me to have an acl object for Network1 (network1_acl) and an
acl object for network2 (network2_acl).
I could just go ahead and setup a constant and pass it in along with the
ids into every load(), save(), remove(), etc calls, but that seems like
a lot of unnecessary crap. Instead, it makes a lot more sense to me to
create a new backend option for my cache id prefix, then have each one
of those methods concat the prefix on to the front of ids automatically
just before the real memcache calls are made.
So, I went about this, and its a real mess. First of all, all options
are hardcoded into the classes and get explicitly checked at object
instantiation. OK, well, I extended Zend_Cache_Backend_Memcached and did
this:
public function __construct($options = array())
{
// add cache id prefix as an allowed option, default nothing
$this-_options['cache_id_prefix'] = null;
// Call parent constructor
parent::__construct($options);
}
Then each one of those methods now look basically like this:
public function load($id, $doNotTestCacheValidity = false)
{
$id = $this-_options['cache_id_prefix'] . $id;
parent::load($id, $doNotTestCacheValidity);
}
Overall, I didn't think that was too big of a deal, but then I realized
that the backends are hardcoded and checked in Zend_Cache, just like the
options, so I'd have to do the same thing for that. What's worse though,
is only the name of the backend is passed in, and then class names are
created and called with a hardcoded 'Zend_Cache_Backend' . $backend. Now
I can't even call my class something different. Now I'd have to create
my class file specifically in the /Zend/Cache/Backend directory, and
call it something like CustomMemcached.
Anyway, overall Zend_Cache is a very nice component with lots of
options, and I appreciate all of them, its just that its very closed.
Maybe that was the intention, and if so, maybe you would accept a patch
file from me to officially add this feature to the memcache backend.
Thanks in advance for reading,
Tony
[fw-general] Major headache trying to tweak or extend Zend_Cache
Zend_Cache seemed very elegant to me at first, until I tried to make a
customization.
I have some apps that will be using memcached for objects. Thing is,
some of my server farms will have multiple sites and networks, all using
the same pool of memcached servers. Of course all the networks will
cache similar named objects, like 'acl' for instance. So, to avoid
namespace trampling, or rather to create namespaces, I thought it'd be
very useful to have cache id prefixes. Now, instead of setting keys in
memecached just called 'obj_name' they'd be 'uniquenetwork_obj_name'.
This allows me to have an acl object for Network1 (network1_acl) and an
acl object for network2 (network2_acl).
I could just go ahead and setup a constant and pass it in along with the
ids into every load(), save(), remove(), etc calls, but that seems like
a lot of unnecessary crap. Instead, it makes a lot more sense to me to
create a new backend option for my cache id prefix, then have each one
of those methods concat the prefix on to the front of ids automatically
just before the real memcache calls are made.
So, I went about this, and its a real mess. First of all, all options
are hardcoded into the classes and get explicitly checked at object
instantiation. OK, well, I extended Zend_Cache_Backend_Memcached and did
this:
public function __construct($options = array())
{
// add cache id prefix as an allowed option, default nothing
$this-_options['cache_id_prefix'] = null;
// Call parent constructor
parent::__construct($options);
}
Then each one of those methods now look basically like this:
public function load($id, $doNotTestCacheValidity = false)
{
$id = $this-_options['cache_id_prefix'] . $id;
parent::load($id, $doNotTestCacheValidity);
}
Overall, I didn't think that was too big of a deal, but then I realized
that the backends are hardcoded and checked in Zend_Cache, just like the
options, so I'd have to do the same thing for that. What's worse though,
is only the name of the backend is passed in, and then class names are
created and called with a hardcoded 'Zend_Cache_Backend' . $backend. Now
I can't even call my class something different. Now I'd have to create
my class file specifically in the /Zend/Cache/Backend directory, and
call it something like CustomMemcached.
Anyway, overall Zend_Cache is a very nice component with lots of
options, and I appreciate all of them, its just that its very closed.
Maybe that was the intention, and if so, maybe you would accept a patch
file from me to officially add this feature to the memcache backend.
Thanks in advance for reading,
Tony
Re: [fw-general] Major headache trying to tweak or extend Zend_Cache
Find attached a patch file for this.
Thanks,
Tony
On 6/7/2007 1:07 PM, Tony Ford wrote:
Zend_Cache seemed very elegant to me at first, until I tried to make a
customization.
I have some apps that will be using memcached for objects. Thing is,
some of my server farms will have multiple sites and networks, all
using the same pool of memcached servers. Of course all the networks
will cache similar named objects, like 'acl' for instance. So, to
avoid namespace trampling, or rather to create namespaces, I thought
it'd be very useful to have cache id prefixes. Now, instead of setting
keys in memecached just called 'obj_name' they'd be
'uniquenetwork_obj_name'. This allows me to have an acl object for
Network1 (network1_acl) and an acl object for network2 (network2_acl).
I could just go ahead and setup a constant and pass it in along with
the ids into every load(), save(), remove(), etc calls, but that seems
like a lot of unnecessary crap. Instead, it makes a lot more sense to
me to create a new backend option for my cache id prefix, then have
each one of those methods concat the prefix on to the front of ids
automatically just before the real memcache calls are made.
So, I went about this, and its a real mess. First of all, all options
are hardcoded into the classes and get explicitly checked at object
instantiation. OK, well, I extended Zend_Cache_Backend_Memcached and
did this:
public function __construct($options = array())
{
// add cache id prefix as an allowed option, default nothing
$this-_options['cache_id_prefix'] = null;
// Call parent constructor
parent::__construct($options);
}
Then each one of those methods now look basically like this:
public function load($id, $doNotTestCacheValidity = false)
{
$id = $this-_options['cache_id_prefix'] . $id;
parent::load($id, $doNotTestCacheValidity);
}
Overall, I didn't think that was too big of a deal, but then I
realized that the backends are hardcoded and checked in Zend_Cache,
just like the options, so I'd have to do the same thing for that.
What's worse though, is only the name of the backend is passed in, and
then class names are created and called with a hardcoded
'Zend_Cache_Backend' . $backend. Now I can't even call my class
something different. Now I'd have to create my class file specifically
in the /Zend/Cache/Backend directory, and call it something like
CustomMemcached.
Anyway, overall Zend_Cache is a very nice component with lots of
options, and I appreciate all of them, its just that its very closed.
Maybe that was the intention, and if so, maybe you would accept a
patch file from me to officially add this feature to the memcache
backend.
Thanks in advance for reading,
Tony
Index: Memcached.php
===
--- Memcached.php (revision 264)
+++ Memcached.php (working copy)
@@ -64,6 +64,9 @@
* = (boolean) compression :
* true if you want to use on-the-fly compression
*
+ * = (string) cache_id_prefix :
+ * prefix for cache ids
+ *
* @var array available options
*/
protected $_options = array(
@@ -72,7 +75,8 @@
'port' = Zend_Cache_Backend_Memcached::DEFAULT_PORT,
'persistent' = Zend_Cache_Backend_Memcached::DEFAULT_PERSISTENT
)),
-'compression' = false
+'compression' = false,
+'cache_id_prefix' = null
);
/**
@@ -98,6 +102,11 @@
Zend_Cache::throwException('The memcache extension must be loaded
for using this backend !');
}
parent::__construct($options);
+if (isset($this-_options['cache_id_prefix'])) { // particular case
for this option
+if (!preg_match('~^[\w]+$~', $this-_options['cache_id_prefix'])) {
+Zend_Cache::throwException('Invalid cache_id_prefix : must use
only [a-zA-A0-9_]');
+}
+}
if (isset($this-_options['servers'])) {
$value= $this-_options['servers'];
if (isset($value['host'])) {
@@ -131,7 +140,7 @@
if ($doNotTestCacheValidity) {
$this-_log(Zend_Cache_Backend_Memcached::load() :
\$doNotTestCacheValidity=true is unsupported by the Memcached backend);
}
-$tmp = $this-_memcache-get($id);
+$tmp = $this-_memcache-get($this-_id($id));
if (is_array($tmp)) {
return $tmp[0];
}
@@ -146,7 +155,7 @@
*/
public function test($id)
{
-$tmp = $this-_memcache-get($id);
+$tmp = $this-_memcache-get($this-_id($id));
if (is_array($tmp)) {
return $tmp[1];
}
@@ -173,7 +182,7 @@
} else {
$flag = 0;
}
-$result = $this-_memcache-set($id, array($data, time()), $flag,
$lifetime);
+$result = $this-_memcache-set($this-_id($id), array($data, time()),
$flag
[fw-general] Any plans for Zend_Controller_Request_Cli?
It would be nice for utilities and especially crons. Support for cli options -r -n as well as arguments would be nice. Just curious ... if not, I'm sure we'll end up implementing one cause we pretty much do not write any perl crons anymore. - Tony
[fw-general] Change property visibility in subclass?
I understand it make no sense to change a private member to protected or
a protected member to public, but what about the other way around? Example:
class Foo
{
public $my_prop = '';
}
class Bar extends Foo
{
protected $my_prop = 'bleh';
}
Why can't I do this in php? I can't think of a reason you should not
be allowed to do this.
Thanks,
Tony
