There are lots of choices, but one thing I've learned: caches are tricky. I try to avoid them. Better to just do the database query multiple times, and let the database handle the cache. That's what they are good at.
-tk On Tue, Nov 13, 2018 at 3:55 PM gjr80 <[email protected]> wrote: > I ask this without having sat and contemplated this deeply, but are there > any other approaches? Is it a case of either the all-in-one approach that > is potentially slow but with the advantage of cached results or the lazy > approach with the advantage of speed but without the cached results. I know > when I put together a SLE it is usually for a specific use so I make a > judgement on which approach suits best but later on others may use this in > a completely different context for which my chosen approach may not suit. > > Gary > > On Wednesday, 14 November 2018 01:02:42 UTC+10, Tom Keffer wrote: >> >> The alltime example uses late binding, as do all the "regular" tags. The >> way you are doing things now, queries like "rainiest day," are being done >> for every template whether or not it actually needs and uses rainiest day. >> >> Off the top of my head, one approach would be to have your SLE return an >> object that encapsulates all these queries as attributes. Then run them >> when requested. The tag would look something like >> $belchertown.at_rainiest_day. The code would look something like >> >> class BelcherTown(object): >> ... >> @property >> def at_rainiest_day(self): >> at_rainiest_day_query = wx_manager.getSql( 'SELECT dateTime, sum FROM >> archive_day_rain ORDER BY sum DESC LIMIT 1' ) >> at_rainiest_day_tuple = (at_rainiest_day_query[1], rain_unit, >> 'group_rain') >> at_rainiest_day_converted = round( >> self.generator.converter.convert(at_rainiest_day_tuple)[0], rain_round ) >> at_rainiest_day = [ time.strftime( "%B %d, %Y at %-I:%M %p", >> time.localtime( at_rainiest_day_query[0] ) ), at_rainiest_day_converted ] >> return at_rainiest_day >> >> (Highly schematic; not tested; maybe wrong, etc., etc.) >> >> The downside of this approach is that the query has to get run for every >> $belchertown.at_rainiest_day tag. No caching of results, like you're doing >> now. >> >> -tk >> >> >> On Tue, Nov 13, 2018 at 6:40 AM Pat O'Brien <[email protected]> wrote: >> >>> Ah, maybe I need to have some more coffee. I had asked if I should move >>> my SQL queries to get_extension_list(), even though they'r already there. >>> Ok this makes sense now. Thanks! >>> >>> Backing up a bit: >>> >>> > You may want to restructure your code to use a later binding. >>> >>> Do you have examples of what I should do, or what a later binding would >>> be? I've stuffed everything into get_extension_list() since that's what >>> sample code, and previous examples have shown. Happy to optimize further if >>> you have a general direction I should follow? Thanks again >>> >>> >>> On Tuesday, November 13, 2018 at 9:14:10 AM UTC-5, Tom Keffer wrote: >>>> >>>> Are you suggesting that every time an $alltime tag is called (even if >>>>> in the same template?), the entirety of $alltime is re-generated? I >>>>> guess that makes sense, but I don't have a grasp on why the values would >>>>> change. Unless it has something to do with the Timebinder changing it's >>>>> time search and the final array of $alltime isn't really "all time". >>>>> >>>>>> >>>> The function get_extension_list() is called every time a template is >>>> processed, whether or not it includes a $alltime tag. So, if you have >>>> 13 templates, it will get called 13 times. Because some templates are "to >>>> date," while others are for a specific time period (by month, or by year), >>>> the "timespan" parameter can vary for each template. >>>> >>>> If you look again at the allstats example >>>> <http://www.weewx.com/docs/customizing.htm#extending_the_list>, you'll >>>> see that all it does in get_extension_list() is build and return >>>> TimespanBinder objects. It doesn't actually hit the database. That >>>> doesn't happen until Cheetah finds a tag with $alltime in it and, even >>>> then, only when the final suffix to $alltime is evaluated (the "max" >>>> in $alltime.outTemp.max). >>>> >>>> -tk >>>> >>>
