DDC-533: Cache keys are not limited to word characters #662

New Issue

admin · 2026-01-22T12:45:55+01:00

admin commented

2026-01-22 12:45:55 +01:00

Originally created by @doctrinebot on GitHub (Apr 21, 2010).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user nicokaiser:

I'm currently working on some glue classes to integrate Doctrine 2 into an existing Zend Framework project.
To be able to re-use our caching classes (which use Zend_Cache), I wrote a \Doctrine\Common\Cache\AbstractCache implementation for Zend_Cache:

http://pastie.org/926891

However Zend_Cache only allows "a-zA-Z0-9_" for cache keys, while Doctrine seems to allow anything, and Doctrine ORM seems to use at lease "" and "$" for metadata storage ("Entity\Article\Category$CLASSMETADATA").

What do you think is the most elegant way to solve this?

Should Doctrine also limit the cache key characters?
How could *encodeId and *decodeId be implemented?

Originally created by @doctrinebot on GitHub (Apr 21, 2010). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user nicokaiser: I'm currently working on some glue classes to integrate Doctrine 2 into an existing Zend Framework project. To be able to re-use our caching classes (which use Zend_Cache), I wrote a \Doctrine\Common\Cache\AbstractCache implementation for Zend_Cache: http://pastie.org/926891 However Zend_Cache only allows "a-zA-Z0-9_" for cache keys, while Doctrine seems to allow anything, and Doctrine ORM seems to use at lease "\" and "$" for metadata storage ("Entity\Article\Category$CLASSMETADATA"). What do you think is the most elegant way to solve this? - Should Doctrine also limit the cache key characters? - How could *encodeId and *decodeId be implemented?

admin added the Bug label 2026-01-22 12:45:55 +01:00

admin closed this issue

2026-01-22 12:45:55 +01:00

admin commented

2026-01-22 12:45:56 +01:00

@doctrinebot commented on GitHub (Apr 21, 2010):

Comment created by nicokaiser:

Currently the cached results and queries are saved with an md5 key anyway, so this works out of the box.

The only ones that make problems are metadata cache, which stores "Entity\Article\Category$CLASSMETADATA". As the Doctrine caching layer can be used separate from the other components, it may be a good idea to still allow arbitrary keys and mapping them internally.

@doctrinebot commented on GitHub (Apr 21, 2010): Comment created by nicokaiser: Currently the cached results and queries are saved with an md5 key anyway, so this works out of the box. The only ones that make problems are metadata cache, which stores "Entity\Article\Category$CLASSMETADATA". As the Doctrine caching layer can be used separate from the other components, it may be a good idea to still allow arbitrary keys and mapping them internally.

admin commented

2026-01-22 12:45:58 +01:00

@doctrinebot commented on GitHub (Apr 21, 2010):

Comment created by nicokaiser:

Don't know the reason for Zend_Cache only supporting "\w+". When using file cache for Zend, it stores the keys in the filenames instead of hashing them, so the allowed characters have to be limited in order to be able to support a wide range of backends (files, database, etc.)...

@doctrinebot commented on GitHub (Apr 21, 2010): Comment created by nicokaiser: Don't know the reason for Zend_Cache only supporting "\w+". When using file cache for Zend, it stores the keys in the filenames instead of hashing them, so the allowed characters have to be limited in order to be able to support a wide range of backends (files, database, etc.)...

admin commented

2026-01-22 12:45:58 +01:00

@doctrinebot commented on GitHub (Apr 21, 2010):

Comment created by nicokaiser:

Even base64 does not work, as it has the "" and "/" characters (and the "=" padding character).

By stripping the = (PHP's base64 implementations does not seem to need it) and escaping and / with the _ (not in base64), it works:

http://pastie.org/927679

But this is a really dirty hack... (md5'ing does not help, as getIds() requires the cache key encoding to be bidirectional)

@doctrinebot commented on GitHub (Apr 21, 2010): Comment created by nicokaiser: Even base64 does not work, as it has the "<ins>" and "/" characters (and the "=" padding character). By stripping the = (PHP's base64 implementations does not seem to need it) and escaping </ins> and / with the _ (not in base64), it works: http://pastie.org/927679 But this is a really dirty hack... (md5'ing does not help, as getIds() requires the cache key encoding to be bidirectional)

admin commented

2026-01-22 12:45:58 +01:00

@doctrinebot commented on GitHub (Aug 30, 2010):

Comment created by romanb:

If the cache keys are going to be changed this needs to happen for RC1, therefore rescheduling.

@doctrinebot commented on GitHub (Aug 30, 2010): Comment created by romanb: If the cache keys are going to be changed this needs to happen for RC1, therefore rescheduling.

admin commented

2026-01-22 12:45:58 +01:00

@doctrinebot commented on GitHub (Sep 16, 2010):

Comment created by @beberlei:

I don't think this is necessary, why would you want to nest a Zend Cache adapter inside a Doctrine Cache instead of just using that cache?

@doctrinebot commented on GitHub (Sep 16, 2010): Comment created by @beberlei: I don't think this is necessary, why would you want to nest a Zend Cache adapter inside a Doctrine Cache instead of just using that cache?

admin commented

2026-01-22 12:45:58 +01:00

@doctrinebot commented on GitHub (Sep 16, 2010):

Comment created by nicokaiser:

When you integrate Doctrine 2 into an existing project that uses, manages and provides Zend_Cache instances? In our case, we have centralized factories that deliver the Zend_Cache instances (depending from configuration, environment, etc.), so we don't want to add additional cache configuration logic for Doctrine.

@doctrinebot commented on GitHub (Sep 16, 2010): Comment created by nicokaiser: When you integrate Doctrine 2 into an existing project that uses, manages and provides Zend_Cache instances? In our case, we have centralized factories that deliver the Zend_Cache instances (depending from configuration, environment, etc.), so we don't want to add additional cache configuration logic for Doctrine.

admin commented

2026-01-22 12:45:58 +01:00

@doctrinebot commented on GitHub (Sep 23, 2010):

Comment created by @guilhermeblanco:

This is not a problem that we need to fix. It's a problem with Zend Framework.
We cannot do anything here. I'd mark it as "Invalid", since it's up to Zend Framework fix their limitation.

If possible I'd make the ClassMetadata hash generator as a configuration extension.
I cannot imagine anything more than this.

@doctrinebot commented on GitHub (Sep 23, 2010): Comment created by @guilhermeblanco: This is not a problem that we need to fix. It's a problem with Zend Framework. We cannot do anything here. I'd mark it as "Invalid", since it's up to Zend Framework fix their limitation. If possible I'd make the ClassMetadata hash generator as a configuration extension. I cannot imagine anything more than this.

admin commented

2026-01-22 12:46:00 +01:00

@doctrinebot commented on GitHub (Sep 24, 2010):

Comment created by @beberlei:

@Guilherme Zend Cahce restricts the keys because of the filesystem cache. It needs proper chars i guess.

@Nico: Why not use str_replace and replace the chars into words?

$key = str*replace(array('\\', '$'), array('__NS__', '__USD_*'), $key);

If you use a cache other than ArrayCache for the Annotations you need to translate that chars also, they contain other stuff that is not filesystem compliant.

@doctrinebot commented on GitHub (Sep 24, 2010): Comment created by @beberlei: @Guilherme Zend Cahce restricts the keys because of the filesystem cache. It needs proper chars i guess. @Nico: Why not use str_replace and replace the chars into words? ``` $key = str*replace(array('\\', '$'), array('__NS__', '__USD_*'), $key); ``` If you use a cache other than ArrayCache for the Annotations you need to translate that chars also, they contain other stuff that is not filesystem compliant.

admin commented

2026-01-22 12:46:00 +01:00

@doctrinebot commented on GitHub (Sep 24, 2010):

Comment created by nicokaiser:

This is the way I do it currently. Not the most elegant way, but it seems to work...
Which other characters are used for Annotations?

@doctrinebot commented on GitHub (Sep 24, 2010): Comment created by nicokaiser: This is the way I do it currently. Not the most elegant way, but it seems to work... Which other characters are used for Annotations?

admin commented

2026-01-22 12:46:00 +01:00

@doctrinebot commented on GitHub (Sep 27, 2010):

Comment created by @beberlei:

$, # and :: (dollar, hash and double colon).

@doctrinebot commented on GitHub (Sep 27, 2010): Comment created by @beberlei: $, # and :: (dollar, hash and double colon).

admin commented

2026-01-22 12:46:02 +01:00

@doctrinebot commented on GitHub (Sep 27, 2010):

Comment created by @beberlei:

Closed, this won't be changed and there is a simple workaround to be applied in the wrapping driver replacing , ::, $, #

@doctrinebot commented on GitHub (Sep 27, 2010): Comment created by @beberlei: Closed, this won't be changed and there is a simple workaround to be applied in the wrapping driver replacing \, ::, $, #

admin commented

2026-01-22 12:46:02 +01:00

@doctrinebot commented on GitHub (Sep 27, 2010):

Issue was closed with resolution "Won't Fix"

@doctrinebot commented on GitHub (Sep 27, 2010): Issue was closed with resolution "Won't Fix"

admin referenced this issue

2026-01-22 16:00:17 +01:00

[PR #662] [MERGED] Fixed a code block. #8517

Sign in to join this conversation.