#011413: ezcCacheStorage::restore should set the search flag to false by default.

Description:

As I noted here: http://issues.ez.no/IssueView.php?Id=10577&activeItem=10

The restore function does not always return the correct data. By default the search functionality should be turned off. If someone wants to turn searching on, they can enable it by setting the search flag to true.

Rationale:
1) Searching is much slower than simply failing if the cache doesn't exist.
2) Failing when the cache doesn't exist would be the expected functionality.
3) Accidentally getting false positives is a terrible user experience but the default setting currently generates false positives.
4) Searching is something that should be done on purpose because it is slower and can lead to unknown errors.

I believe that in ezcCacheStorage::delete, searching by default is just fine. This is less prone to errors and will not diminish the user experience as much.

Environment:

Operating System:
PHP Version: (please be specific, like '4.4.3' or '5.1.5')
Database and version:
Browser (and version):

Attachments

No attachments for this issue.

Comments

If the default behaviour is "search=on" then changing it to "search=off" would create a backwards compatibility. I think it should remain as it is.

What do other people think?

#253823 by Alexandru Stanoi on September 26th, 2007 [Permanent Link]

The search function returning the wrong data is a very big deal. This can cause people to think the cache isn't working and completely lose faith in it. This has been a major problem for some of our larger implementations that utilize ezComponents. I would consider the cache mechanism returning the wrong data by default a huge fault in the product. I know that my clients consider it a huge fault in their applications. I would say this is worth a possible backwards compatibility issue.

I am aware that it can be turned off and I have to do this in all of my functions. But developers that are not careful would still be prone to leave off the false as the last argument and open themselves up to returning bad data.

#253831 by Grady Kuhnline on September 26th, 2007 [Permanent Link]

I tend to agree with this... but it does break BC :-/

#253984 by Derick Rethans on October 4th, 2007 [Permanent Link]

Fixed in rev. 6376. The search flag is off for both restore() and delete(). The fix will be available in Cache 1.3alpha1.

#254017 by Alexandru Stanoi on October 5th, 2007 [Permanent Link]

I think this is the right decision. In fact, it seems like the search functionality was a bad idea from the start. While this change breaks BC, it can be considered a bug-fix, I think. Actually I would suggest to remove the search functionality integration from the affected methods and just offer it as a method on its own, to avoid confusion. But that might be a too drastical break?

#254027 by Tobias Schlitt on October 8th, 2007 [Permanent Link]

The search functionality is very useful for the delete functionality. However, I have most often used it as a "delete all". I have never had a use-case that required searching while fetching. I agree that separating the functions would lower confusion.

restoreSearch()
deleteSearch()

#254034 by Grady Kuhnline on October 8th, 2007 [Permanent Link]

Links

No links for this issue.

History

Load History

Properties

Type		Bug

Priority		Medium

Component		Components » Cache

Affects		1.2 - Cache 1.2

Fix Versions		1.3alpha1 - Cache 1.3alpha1 2007.2alpha1 - eZ components 2007.2alpha1

Reporter		Grady Kuhnline

Responsible		Alexandru Stanoi

Status		Closed

Resolution		Fixed

Created		September 7th, 2007

Updated		October 16th, 2007

Resolved		October 5th, 2007