Keep query parameters as-is

Yii 1.1 General Discussion
1

The CUrlManager supports two URL formats: get (default) and path. The URL


http://hostname/?r=controller/action&query=value

is equivalent to


http://hostname/controller/action/query/value

My question is, is it possible the use the path URL format while keeping the query parameters as the get foramt, like


http://hostname/controller/action?query=value

If yes, how to configure the CUrlManager and potentially htaccess? Thank you!

2

define properties ‘format’ to ‘path’ and ‘appendParams’ to false

3

How could I ignore that? Thank you!

BTW, Gustavo, do you remember you have a RedisCache extension. It is based on Predis. Yesterday I wrote a RedisCache based on phpredis. Most of the code is referred from your extension and CMemCache. I noticed one problem that in your RedisCache, you implemented offsetExists(). Since CCache::set() actually pass the hashed key (generateUniqueKey()) to setValue(), how do you make offsetExists() work without wrapping generateUniqueKey() inside? Do you expect caller generate hashed key before calling offsetExists()?

Thanks!

4

True

How could I miss that ?

Its working properly tho, not sure how

The correct format should be


return $this->getRedis()->exists($this->generateUniqueKey($id));

I’ve been working with this extension for some days now and changed a lot of things, as I’m implementing a active record based on redis, still in development tho, using this redis extension

For now its great (fast as a lightning). Still has a with a lot of bugs, I’ll release it as an extension when I’m done and its stable

May I know why phpredis instead of predis ?

Cheers,

Gustavo

5

Yii implements as




public function offsetExists($id)

{

    return $this->get($id)!==false;

}

but not require us to override it

CCache::offsetSet() forwards parameters to CCache::set(). Even if user calls offsetSet() then offsetExists(), he/she won’t get expected result. What’s the logic behind the offset series functions?

predis vs phpredis? I guess you can find many different answers over Google/Stack Overflow. In my mind, performance and functionality are the main advantages. This post is resourceful (phpredis author is also in discussion).

6

CCache implements ArrayAccess, so you can use it as an array, therefore the call


isset(Yii::app()->cache['something'])

will call offsetExists

yes, but redis method "exists" is faster that get, 1 reason is because it returns boolean instead of the actual value of the key, thats why the need to override

I’ll read the post and might migrate if its actually faster and more functional

EDIT:

Its write in C, that why the performance gain

phpredis methods are not 100% consistent with redis, which is not good, as you must check predis documentation instead of redis

7

If you do not override offsetSet(), can you use


Yii::app()->cache[$key] = $value

Since you implement __call(), I would prefer to stick with one coding style by using get(), set(), exists().

Which part of phpredis is not consistent with Redis? The pipelining part? I’m very new to Redis, therefore I’m not sure if I would rely on the features that are inconsistent. According to their benchmark, 2-3 times gain on performance is not simply ignorable.

8

name incosistence I mean

For example

mget -> getMultiple

del -> delete

and so on, that is what I mean

You can check all the differences comparing:

http://code.google.com/p/phpredis/wiki/referencemethods

http://redis.io/commands

but you are right, if the gain is that much, It’s worth to learn the naming differences

I can’t make tests here, but I’ll later with time and see for myself

I’ll post a new version of redisCache fixing the bug you found

Cheers

Gustavo

9

I just want to point out that https://github.com/nicolasff/phpredis is phpredis homepage (linked by redis.io). There is del(). There is mset(). There is hMGet(). There is no mget() but instead getMultiple(). Could "mget" reserved by PHP or something?

Also, can you explain a little bit about the generateUniqueKey() and keyPrefix? Isn’t the users responsible to make keys unique (if they are meant to be unique)?

10

keyPrefix is for the case in which you use the same cache system for more than 1 application, avoiding conflicts

as for uniqueKey, I’m not sure, but I guess that it is to prevent problems, when a cache system does not accept non-alpha characters as key

mget is used by predis , maybe it is in reserved in C ?

true, they changed it since I last saw, now its closer to redis, thats good