Asking for info about cached queries and views

42 views
Skip to first unread message

Vahrokh Vain

unread,
Sep 30, 2016, 3:18:26 PM9/30/16
to Fat-Free Framework
Hello,

I know of some frameworks which, like f3, allow to cache query results and rendered views.

Most of those frameworks have two issues and I need to know if f3 has got them or not:

1) You can't cache any but the simplest queries, because if you use parameters the next user is going to see the previous user cached result set.

Example:


select * from companies

can be safely cached because the same result set is going to come up.


Likewise, a cached template rendering a view is safe to use in this specific case.

select * from companies where company_id = :id

this cannot be safely cached because if I query the database for :id = 10 and 3 seconds later a second user queries the database for :id = 5, he's going to see my cached result set calculated on :id = 10.


Is f3 able to deal with this? Do I need to do something on my side or is it automatic?



2) You can't cache anything but "fixed" views.

Example:

A view returning U.S.A. states list can be safely cached.

A view returning an invoice is tied to the current user and cannot be cached, otherwise the next user is going to see the previous user's invoice.


Is f3 able to deal with this? Do I need to do something on my side or is it automatic?


3) I am not going to ask about routes caching because I have found out they cannot be "safely" cached: in case the rendered view changes, the code still shows the old cached view.

Roberto Gomes

unread,
Sep 30, 2016, 5:42:41 PM9/30/16
to f3-fra...@googlegroups.com, f3-framework+APn2wQcqnELOK49uNxX...@googlegroups.com
Ok, first of all, these caching issues you mention apply to most languages/frameworks and are pretty much the core of caching methodologies and therefore are the main reason for most caching strategies to even exist in the first place.

AFAIK, F3 should cache queries perfectly fine as long as the parameters are different so a "WHERE id=x" should never conflict with "WHERE id=y".

As a second note, there's no way you need to cache an invoice that's most likely specific to one person and they'll only print or view it at most a couple of times. Don't use caching unless it's something that really needs to be cached (most likely for speed and memory concerns).




--
-- You've received this message because you are subscribed to the Google Groups group. To post to this group, send an email to f3-fra...@googlegroups.com. To unsubscribe from this group, send an email to f3-framework+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/f3-framework?hl=en
---
You received this message because you are subscribed to the Google Groups "Fat-Free Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to f3-framework+unsubscribe@googlegroups.com.
To post to this group, send email to f3-fra...@googlegroups.com.
Visit this group at https://groups.google.com/group/f3-framework.
To view this discussion on the web visit https://groups.google.com/d/msgid/f3-framework/bf0ea5ea-23fd-453b-8913-8265e92861d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Vahrokh Vain

unread,
Sep 30, 2016, 6:58:20 PM9/30/16
to Fat-Free Framework
Thank you.

Could you please tell me if I must use an explicit, "old style" query like:

... where id =x


or if the f3 cache works if I use a parameter in place of x?

Because I'd really prefer using parametric queries, but I understand that you can easily create an hash query entry unique ID by hashing the query text (so, id=5 is going to yield a differend hash than id=10 etc). It's less clear if it's able to detect different queries if their string is the same (which is the case if I use a parameter, the parameter name does not change if I hash the query string including it).




On Friday, September 30, 2016 at 10:42:41 PM UTC+1, ved wrote:
Ok, first of all, these caching issues you mention apply to most languages/frameworks and are pretty much the core of caching methodologies and therefore are the main reason for most caching strategies to even exist in the first place.

AFAIK, F3 should cache queries perfectly fine as long as the parameters are different so a "WHERE id=x" should never conflict with "WHERE id=y".

As a second note, there's no way you need to cache an invoice that's most likely specific to one person and they'll only print or view it at most a couple of times. Don't use caching unless it's something that really needs to be cached (most likely for speed and memory concerns).



On Fri, Sep 30, 2016 at 8:18 PM, Vahrokh Vain via Fat-Free Framework wrote:
Hello,

I know of some frameworks which, like f3, allow to cache query results and rendered views.

Most of those frameworks have two issues and I need to know if f3 has got them or not:

1) You can't cache any but the simplest queries, because if you use parameters the next user is going to see the previous user cached result set.

Example:


select * from companies

can be safely cached because the same result set is going to come up.


Likewise, a cached template rendering a view is safe to use in this specific case.

select * from companies where company_id = :id

this cannot be safely cached because if I query the database for :id = 10 and 3 seconds later a second user queries the database for :id = 5, he's going to see my cached result set calculated on :id = 10.


Is f3 able to deal with this? Do I need to do something on my side or is it automatic?



2) You can't cache anything but "fixed" views.

Example:

A view returning U.S.A. states list can be safely cached.

A view returning an invoice is tied to the current user and cannot be cached, otherwise the next user is going to see the previous user's invoice.


Is f3 able to deal with this? Do I need to do something on my side or is it automatic?


3) I am not going to ask about routes caching because I have found out they cannot be "safely" cached: in case the rendered view changes, the code still shows the old cached view.

--
-- You've received this message because you are subscribed to the Google Groups group. To post to this group, send an email to f3-fra...@googlegroups.com. To unsubscribe from this group, send an email to f3-framework...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/f3-framework?hl=en

---
You received this message because you are subscribed to the Google Groups "Fat-Free Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to f3-framework...@googlegroups.com.

ikkez

unread,
Sep 30, 2016, 8:33:57 PM9/30/16
to f3-fra...@googlegroups.com
yes it does exactly what you have described. It uses the query string and the given parameters and creates a hash from them. So yes it works with prepared statements, and also without, with all mappers and at many other points in the framework. watch out for the $ttl parameter. Depending on your needs, you can create a multi-layer cache, starting at caching the full route (probably not the best way for dynamic pages), custom results in your controller, direct mapper or database results, templates, dictionaries,.. nearly everything important has build-in caching methods. And adding own things to the cache is really simple.

Vahrokh Vain

unread,
Oct 1, 2016, 6:33:33 AM10/1/16
to Fat-Free Framework
Thank you, to both of you!
Reply all
Reply to author
Forward
0 new messages