I'm sure we are saying the same thing, but just to clarify... I was talking about the actual evaluation of any Cheetah expressions. They get called for each expression.
By contrast, get_extension_list() gets called once for each template, irregardless of whether any SLEs it may define appear in a template. Its job is to discover the SLEs and to bind them to the default database and the timespan for each template. Smart SLEs just quietly tuck that information away then do nothing. They wait until the actual Cheetah expression gets evaluated before doing any heavy lifting. I suppose we could refactor get_extension_list() into two functions: one that returns any SLEs, then another that binds those SLEs to the default database and timespan for a template. This would require SLEs to be written in a such a manner that what is now a one-step process would be done in a two-step process. That's a lot of extra complexity for not much gain. Still another alternative would be to allow (require?) that SLE's be declared on a template-by-template basis. Then they would not get defined at all unless they were used. There might be a backwards compatible way to do this, but I see the gains as pretty marginal. -tk On Sun, Jun 25, 2017 at 5:53 PM, gjr80 <gjroder...@gmail.com> wrote: > On Monday, 26 June 2017 10:35:35 UTC+10, Tom Keffer wrote: >> >> Say you have two SLEs. The first one defines foo, the second bar. >> Furthermore, say we have a template containing >> >> $bar.outTemp >> $bar.barometer >> $bar.whiz >> >> As Cheetah evaluates these, it will try the "foo" extension first >> (because it's first in the list). But, because foo doesn't define bar, it >> moves on to the next extension in the list. The "bar" extension does define >> it, so it gets a hit. Cheetah then tries to evaluate the attributes >> 'outTemp', 'barometer', 'whiz' on the results. >> > > Agreed, I think whether the database is hit or not depends on what the SLE > is returning. If it is returning a complex calculated result as say a > ValueTuple, then the database access was all done during the SLE execution, > whereas if it is returning some sort of timespan binder (maybe not the > technically correct term but I hope you know what I mean) the database hit > occurs after as requried. > > >> So, the foo extension did get probed, but not far enough to do the full >> evaluation. Because the standard weewx extensions use lazy evaluation, that >> means the database never actually gets queried. >> >> I'm not sure I'm being very clear here and I'm not sure I addressed your >> point. If not, and I'm missing something, I'd sure like to know! >> > > Perhaps if I explain my observations (non-weather!) it might help. > > I have a SLE that returns some data, it does not matter what the data is. > Immediately before the return statement at the end of the SLE > get_extension_list() method, I have a debug syslog statement that logs > the execution time of the SLE. I have a skin that includes four reports, in > the skin the search_list_extension option includes the SLE just > mentioned. Only one of the reports uses the result returned by the SLE. > When I run weeWX with debug=1 I see four syslog entries with execution > times for the SLE. This tells me the SLE get_extension_list() method was > called four times. > > Whether or not the database was hit really depends on the SLE, but the SLE > get_extension_list() method is executed once for each report. > > Gary > > -- > You received this message because you are subscribed to the Google Groups > "weewx-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to weewx-user+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
