User-flags related changes cause issues during inheritance

[mkoppanen]

More information:

symfony/symfony#9797

https://bugs.php.net/bug.php?id=66331

[mkoppanen]

Trying to figure out a fix for this before next beta.

[mkoppanen]

After some discussions on IRC it doesn't look like there is an easy fix for this. //cc @poison

[quipo]

Hi Mikko,

we stumbled onto this bug whilst testing PHP 5.5.8. The latest stable php-memcached version (2.1.0) does not compile with PHP 5.5, and 2.2.0b1 has this inheritance bug, so we're kind of stuck between a rock and a hard place.

What is the new functionality actually used for? Do you have use cases that explain it? How is #125 breaking the tests?

[mkoppanen]

The userflags parameter was added to to be able to set what the name says, numeric flags on keys. This allows for example versioning keys between application releases. The problem (if I remember correctly) is that if cas tokens is not prefer_ref the following signature would not work:

get ($key, null, null, $user_flags)

due to only variables being able to be passed by reference. user flags have not been released in a stable release yet so there is still a bit wiggle room on how to fix this. However the inherent issue is actually with PHP rather than memcached extension.

[poison]

The problem is that there's no real function overloading in PHP. We tried to solve this by detecting if parameters are passed by reference or if they are null, but I didn't know that this was causing issues with inheritance. Maybe we should add a ./configure parameter with --enable-user-flags which is currently default off until this PHP bug is fixed. What do you think @mkoppanen?

Next to that I'm wondering what the real purpose is of extending the memcached connector (as opposed to encapsulating it). But this is ofcourse beyond the scope of this discussion.

[mkoppanen]

I am not a huge fan of changing signature based on configuration parameter as it makes writing portable code quite hard. One option that might be a work-around is to make cas_tokens a ref, which would mean that null wouldn't work but ($cas_tokens = null) would. Another option I can see is making additional call "getUserFlags", which would retrieve user flags from previous call. Neither solution seems ideal to me, but the notice might cause problems for users.

As for your comment on extending the connector, when you create mocks in PHPUnit it will trigger this notice.

[mkoppanen]

I think I would be leaning on setting cas_tokens to ref instead prefer_ref and changing it in the future when PHP compiler is fixed. The downside of this is that all calls that use userflags would also have cas set on. Not sure how big of an issue this is.

[poison]

I'm not sure what the impact of enabling CAS on every operation is, but I think it gives extra cpu cycles to the memcached daemon. I'll try to verify this. If that's the case I'm not a huge fan of this, unless we add the ability to disable CAS on the connector completely (eg.: BEHAVIOUR_IGNORE_CAS). We do start our memcached servers with -C (= disable the use of CAS (and reduce the per-item size by 8 bytes)).

[mkoppanen]

Yes, I think additional cycles are used on both client and server side. There is no ability to disable CAS completely. In your use-case, are user flags usually the same for all items? If they are the following api might be possibly ok:

Add Memcached::OPT_USER_FLAGS, which can be set/get via the normal setOption/getOption and add additional call getLastUserFlags, which returns user flags from the latest call. Does this sound workable or does it make the use more awkward?

[mkoppanen]

So, while this causes issues to symfony (phpunit?) folks and possible misc users I am inclined to carry on with next release with the functionality as is. The inherent problem here is the PHP bug 66331 and I don't think we should change our API to accommodate for this. Opinions?

[quipo]

Whilst people might still hit this issue when extending memcache, it's easy to work around it by using composition instead, so not a big deal. Unless you need to mock the class with PHPUnit, of course.