[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Straw-devel] nasty: confused feeds
From: |
Juri Pakaste |
Subject: |
Re: [Straw-devel] nasty: confused feeds |
Date: |
Sat, 25 Oct 2003 11:17:39 +0300 |
I really excel at this monologue thing. Yet another reply to myself:
On Sat, 2003-10-25 at 10:19, Juri Pakaste wrote:
> On Sat, 2003-10-25 at 09:21, Juri Pakaste wrote:
> > ItemStore is somehow confused. After all, we only write there after
> > startup, we don't read anything back (well, except for images, but that
> > doesn't matter here.)
>
> The whole feed restoration part is maybe a bit fishy, now that I look at
> it, but I can't see with a quick glance what's causing this. But for
> whatever reason, apparently the sequence isn't remembered between
> sessions.
It's a two-part problem, really, caused partially by slight problem with
the whole event mechanism, or at least how it interacts with config.
First of all, Feed.__init__ always requests a new id from the sequence.
And we construct new Feeds when restoring them from the db. Result:
after each restart, feed_id_seq = feed_id_seq + len(config.feeds).
Second, in the CVS version, we did the feed restoration first, the
feed_id_seq restoration next. Now, because of the way the signals bounce
around, what happened was that we saved configuration after the feeds
had been restored, including the feed_id_seq. And feed_id_seq is of
course initialized to zero before it's been restored from the saved
configuration. So:
1) feed_id_seq = 0
2) restore feeds, each feed increments feed_id_seq (after construction,
their real ids are restored from the db)
3) save configuration, including feed_id_seq which is now
len(config.feeds)
4) restore feed_id_seq, which isn't what we saved last time something
really changed, but instead what we saved in step 3.
Not very good, no.
I've committed a partial fix. Now we only connect configsaver to the
signal after loading the options, and as an extra measure (well,
something I tried first when poking around and didn't bother to remove)
first restore feed_id_seq. With this change, we at least don't lose the
feed_id_seq order and behave a bit more sanely in other ways too (that
is, don't save the configuration while loading it), but it's still not
very good - feed_id_seq is still incremented by the number of feeds at
startup, and that gets saved any time the configuration is saved. And
that is more often than you'd imagine :-)
I'll really have to do something about the feed restoration thing.
--
[ Juri Pakaste / address@hidden / http://www.iki.fi/juri/ ]