Posts::get()

[Scott Merrill]

There's been a comment in there for a very long time stating
* <b>THIS CLASS SHOULD CACHE QUERY RESULTS!</b>
Is this still valid? Should the class cache query results, or should
it rely on a true caching infrastructure? I guess the question is: do
we think this class will be used to execute the same query more than
once, such that caching the results in the object through the life of
the current request actually be helpful? If we do, an easy way to do
that is to (normalize and) serialize the array arguments passed to the
get() method and use that (or a hashed value of it) as an index into
an array of queries and results. That way we can identify if a query
is asking for something we've already fetched.

[Blake Johnson]

I suspect that what we need is a true caching infrastructure, but we
should develop some tests to log what calls are sent to Posts::get()
in a single page view. If we are duplicating requests, then your
suggestion would speed things up.

--Blake

[Andrew da Silva]

The method you refer to is the approach that makes sense and should
work well.

Although I wouldn't serialize the array, just create a md5 key or
whichever hash generating function.

Unless serialize() is faster?

On May 23, 6:59 pm, "Scott Merrill" <ski...@skippy.net> wrote:

[Chris Meller]

md5() expects a string, so you'd need to serialize the array first anyway.

I would say that there is no down-side to some extra caching, and a potentially great benefit, so why not add in some caching? Just make sure that the 'index' structure is such that you can easily wipe out all the cached results when a post is published / updated, so we can always ensure that what's being returned from Posts::get() is the most current data.

[Christopher Davis]

I agree. I don't really see a downside in throwing some cache around on the get().

[Caius Durling]

Maybe include a pre-cache hook in there as well, so stuff like
markdown parsing can happen once, and then the cache is just serving
up text. Although thats probably more in the realm of a full caching
infrastructure..?

C

On May 24, 8:45 pm, Christopher Davis <c...@chrisjdavis.org> wrote:
> I agree. I don't really see a downside in throwing some cache around  
> on the get().
> On May 24, 2008, at 2:59 PM, Chris Meller wrote:
>
> > md5() expects a string, so you'd need to serialize the array first  
> > anyway.
>
> > I would say that there is no down-side to some extra caching, and a  
> > potentially great benefit, so why not add in some caching? Just make  
> > sure that the 'index' structure is such that you can easily wipe out  
> > all the cached results when a post is published / updated, so we can  
> > always ensure that what's being returned from Posts::get() is the  
> > most current data.
>

> > On Sat, May 24, 2008 at 2:22 PM, Andrew da Silva <andrewdasi...@mac.com