> On Feb. 26, 2013, 7:15 p.m., Tim Flink wrote: > > Code looks good to me for the most part. I realize that we've talked about > > g versus session for storing this data before but I'm hitting some minor > > issues regarding the ability of the menu bars to update. > > > > When I start adding/removing milestones, the only way that the menu bar is > > updated is if I start a new browser session - this means quitting the > > browser and re-starting _without_ restoring the previous session. There > > might be a better way to force a refresh but either way, I'm not so sure > > about putting the refresh burden on users instead of handling it in the app. > > > > Unfortunately, I can't think of many good ways to make this work well that > > don't involve an extra database query per request. One way would be to have > > a statically defined expiration in the session (like 1 day after initial > > load) and force refresh after that expiration. However, that has its own > > pitfalls and adds complexity - I'm not convinced this is a good idea. > > > > I'm wondering if it wouldn't be better to go back to what you had initially > > and use g. It would involve extra database queries but if that becomes a > > problem, caching would work well to reduce server load - most of the > > content is relatively static (in the timeframe of sync operations, 30 > > minutes right now) and caching could be a good way to work around this. > > Martin Krizek wrote: > In general, I agree. However, and please correct me if I am wrong, our > use case is to put milestones into db before the testing starts (before the > app is actually used by anyone). Then there is a testing period and then > there is a testing break during which the session expires. And after the > break we put the new milestones into db again. In this scenario I don't see > the problem with refreshing the milestones. Or do we add/delete/change > milestones during the testing period? Or are we planning to do that? If so, > we should use the g object, otherwise, I think we're better off with session.
True, the risk of having problems during the testing of a release are relatively small but I'd still rather not have to tell people to quit their browser or delete a cookie when new milestones aren't showing up in their browser. One possible solution would be to hack at permanent sessions so that the lifetime is something like 1 day (http://stackoverflow.com/questions/11783025/is-there-an-easy-way-to-make-sessions-timeout-in-flask) but honestly, I'm thinking that the use of g would be a better solution right now - postgres is supposed to be good at caching query results and this one shouldn't change all that often - if we end up with performance problems, we can always revisit. The change from g to session isn't much code. - Tim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/8/#review10 ----------------------------------------------------------- On Feb. 26, 2013, 9:28 a.m., Martin Krizek wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard-tflink.rhcloud.com/r/8/ > ----------------------------------------------------------- > > (Updated Feb. 26, 2013, 9:28 a.m.) > > > Review request for blockerbugs. > > > Bugs: 332 > https://fedorahosted.org/fedora-qa/ticket/332 > > > Repository: blockerbugs > > > Description > ------- > > Make navigation bar content loaded dynamically > > > Diffs > ----- > > blockerbugs/templates/index.html 17b98b686664754de74158afb4c793e245660690 > blockerbugs/templates/base_nav.html > f3a89798a9dadf297e722c067ad3795a72ebbf74 > blockerbugs/controllers/main.py e7525f8433d74802f7c0cb2d719f0abdc13431c4 > > Diff: http://reviewboard-tflink.rhcloud.com/r/8/diff/ > > > Testing > ------- > > > Thanks, > > Martin Krizek > >
_______________________________________________ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
