Change to TQL: setCacheEvaluation() by default set to 'true' ?

[Mark Mandel]

Hey all,

This has been discussed before, but in light of some cool new pieces (which I just got to my email via Elliot Sprehn, thank you very much!), leads me to finally switch the setCacheEvaluation() on the TQL query object to 'true', rather than 'false'.

See:
http://docs.transfer-orm.com/html/transferapi//transfer/com/tql/Query.html#setCacheEvaluation()

It looks like for almost all operations, you're going to set it to true regardless, so why not have it true in the first place?

What do you guys think?

Mark

--
E: mark....@gmail.com
W: www.compoundtheory.com

[Bob Silverberg]

I have a number of TQL queries for which I am counting on the default
to be "false", so this would require me to go through my code and
change those to explicitly set it to "false". That's not that big a
deal for me at this point, but it might be a bigger deal for others.

For the most part the cases in which I need CacheEvaluation to be
false are queries where I am dynamically building the WHERE clause,
based on which criteria is specified by the user. Just to make sure
I'm understanding this setting; is that correct, that I would need
CacheEvaluation to be "false" if I am building a dynamic query?

Thanks,
Bob

--
Bob Silverberg
www.silverwareconsulting.com

[Elliott]

No. You can, and probably should, cache the evaluation there too. The
docs are very confusing about what this setting really does.

Transfer generates a data structure by parsing your TQL. So "select *
from user.User where user.id = :userId" generates a data structure
that represents that query. This can be reused for all queries that
would have used that TQL. Reasonably sure it ignores whitespace too,
so even two queries with different spacing use that same cached data
structure.

So if we dynamically build up the where clause based on some input
like:

<cfif structKeyExists(params,"v1")>
and v1 = :param1
</cfif>
<cfif structKeyExists(params,"v2")>
and v2 = :param2
</cfif>
...

We can still cache the evaluation because there's a finite set of
possible combinations of TQL that could be generated. ({},{v1},{v2},
{v1,v2}).

The one possible place I could think where you might want to disable
caching is if you had some kind of input box on your site that allowed
the user to enter arbitrary TQL (like literally write the tql query).
Now, since the user can throw any combination of TQL they want at your
server, you could end up caching hundreds of different combinations
(order of where clause, order clause, result columns, etc.).

Your code in your models/services, in general, probably generates TQL
around some finite set, like the example above, though. So using the
cache should be fine.

The performance gain of using the eval cache is also *HUGE*. Using a
little more memory to cache the 4 different possible combinations from
your dynamic query is probably worth it!

- Elliott

On Jun 30, 2:02 pm, "Bob Silverberg" <bob.silverb...@gmail.com> wrote:
> I have a number of TQL queries for which I am counting on the default
> to be "false", so this would require me to go through my code and
> change those to explicitly set it to "false".  That's not that big a
> deal for me at this point, but it might be a bigger deal for others.
>
> For the most part the cases in which I need CacheEvaluation to be
> false are queries where I am dynamically building the WHERE clause,
> based on which criteria is specified by the user.  Just to make sure
> I'm understanding this setting; is that correct, that I would need
> CacheEvaluation to be "false" if I am building a dynamic query?
>
> Thanks,
> Bob
>
>
>
> On Mon, Jun 30, 2008 at 1:48 AM, Mark Mandel <mark.man...@gmail.com> wrote:
> > Hey all,
>
> > This has been discussed before, but in light of some cool new pieces (which
> > I just got to my email via Elliot Sprehn, thank you very much!), leads me to
> > finally switch the setCacheEvaluation() on the TQL query object to 'true',
> > rather than 'false'.
>
> > See:

> >http://docs.transfer-orm.com/html/transferapi//transfer/com/tql/Query...()

>
> > It looks like for almost all operations, you're going to set it to true
> > regardless, so why not have it true in the first place?
>
> > What do you guys think?
>
> > Mark
>
> > --

> > E: mark.man...@gmail.com
> > W:www.compoundtheory.com
>
> --
> Bob Silverbergwww.silverwareconsulting.com

[Bob Silverberg]

Thanks Elliott, I didn't know this is what it did, but I guess that
makes sense. Otherwise, what _would_ it be caching? That's a great
explanation. I wonder how many others have had the same
misunderstanding as I?

Bob

--
Bob Silverberg
www.silverwareconsulting.com

[Mark Mandel]

How can we change the explanation so it is clearer? I added in a few extra lines, so hopefully it makes more sense.

I assume everyone else is totally fine with the change? Silence is considered consent.
http://docs.transfer-orm.com/wiki/Transfer_Query_Language.cfm

Mark

[Bob Silverberg]

Mark,

Currently on the wiki it says this:

-----------
When the structure of your TQL is not going to change between calls
(mapped param values may change, but your actual TQL isn't) , you can
tell Transfer to cache the evaluation of the TQL, which gives
significant performance boosts. To do this, you simply need to:

query.setCacheEvaluation(true);

This will allow Transfer to cache the evaluation of TQL -> SQL, so it
doesn't have to be re-done every time the TQL is executed.

By default evaluation caching is set to false.
-----------

Does this not reflect the few extra lines you refer to in your email,
'cause it still seems to say to me what I _thought_?

When you say "When the structure of your TQL is not going to change
between calls (mapped param values may change, but your actual TQL
isn't)", that leads me to believe that dynamic TQL should not be
cached. Is the case you are referring to here one of reusing a query
within a single request, with the mapped params changing? If so,
perhaps saying that would make it clearer. If not, can you provide an
example of a situation in which one _should_
setCacheEvaluation(false)?

Cheers,
Bob

--
Bob Silverberg
www.silverwareconsulting.com

[Elliott Sprehn]

On Jul 1, 7:41 am, "Bob Silverberg" <bob.silverb...@gmail.com> wrote:
> Mark,

>
> When you say "When the structure of your TQL is not going to change
> between calls (mapped param values may change, but your actual TQL
> isn't)", that leads me to believe that dynamic TQL should not be
> cached.  

I agree. The line about the "structure of the query" changing is very
confusing. Strings are immutable in CF, and you can't reuse queries,
so I'm not sure what "structure" could change between calls which
would prevent you from caching the query.

> Is the case you are referring to here one of reusing a query
> within a single request, with the mapped params changing?  

It is never safe to do this. Transfer pools the Query objects
internally and they are not reusable. Once you've executed the query
you *must* ask transfer for a new one, even if you want to do the same
query again.

- Elliott

[Mark Mandel]

Maybe it should be:

--
Only when your TQL statement is going to be vastly different between calls, should you set query.setCacheEvaluation(false);

This is because when set to 'true', the TQL=>SQL conversion is cached, and can be reused, even if the mapped param values change.  This can be an large performance boost for TQL operations.
--

Does that make more sense?

Mark

[Elliott Sprehn]

What about:

""
Transfer caches the SQL which is generated from your TQL query when
executing queries to increase performance. This cached evaluation is
not specific to the mapped parameter values that are used in the
query. This cache is enabled by default.

When dynamically generating TQL queries that will *never* be executed
again, or executing a large number of vastly different TQL queries you
may disable the evaluation cache to save memory.

In general you should not modify this setting.

To disable the cache call:

query.setCacheEvaluation(false);

""

On Jul 1, 6:50 pm, "Mark Mandel" <mark.man...@gmail.com> wrote:
> Maybe it should be:
>
> --
> Only when your TQL statement is going to be vastly different between calls,
> should you set query.setCacheEvaluation(false);
>
> This is because when set to 'true', the TQL=>SQL conversion is cached, and
> can be reused, even if the mapped param values change.  This can be an large
> performance boost for TQL operations.
> --
>
> Does that make more sense?
>
> Mark
>

> On Tue, Jul 1, 2008 at 9:41 PM, Bob Silverberg <bob.silverb...@gmail.com>

> > On Tue, Jul 1, 2008 at 3:22 AM, Mark Mandel <mark.man...@gmail.com> wrote:
> > > How can we change the explanation so it is clearer? I added in a few
> > extra
> > > lines, so hopefully it makes more sense.
>
> > > I assume everyone else is totally fine with the change? Silence is
> > > considered consent.
> > >http://docs.transfer-orm.com/wiki/Transfer_Query_Language.cfm
>
> > > Mark
>

> > > On Tue, Jul 1, 2008 at 5:31 AM, Bob Silverberg <bob.silverb...@gmail.com

>
> > > wrote:
>
> > >> Thanks Elliott, I didn't know this is what it did, but I guess that
> > >> makes sense.  Otherwise, what _would_ it be caching?  That's a great
> > >> explanation.  I wonder how many others have had the same
> > >> misunderstanding as I?
>
> > >> Bob
>

> >http://docs.transfer-orm.com/html/transferapi//transfer/com/tql/Query...()<http://docs.transfer-orm.com/html/transferapi//transfer/com/tql/Query...>

[Mark Mandel]

I like it!

Although, that assumes that we've all agreed that it should be 'true' by default.

Which we all agree on? Bob, your thoughts?

Mark

[Bob Silverberg]

I like Elliott's description. That makes it very clear. As for
changing the default, I have absolutely no problem with that, as
really I should be using true for all of my calls anyway.

Thanks for asking,
Bob

--
Bob Silverberg
www.silverwareconsulting.com

[Sean Corfield]

+1 on changing the default. I don't have a single TQL query where I
don't set it to true so it would save me typing!

And I like Elliott's new words too.

[John Allen]

another +1 for default. I always set it to true as well.

[Mark Mandel]

This has now been completed
http://tracker.transfer-orm.com/issue.cfm?p=89977683-A728-9CD3-ABD9545A91734422&i=E0450001-A9EE-8C3D-764763B7CCE89627

Mark

--
E: mark....@gmail.com
W: www.compoundtheory.com