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] > <javascript:>> 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 >>> >>
