straw-devel
[Top][All Lists]
Advanced

[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/ ]





reply via email to

[Prev in Thread] Current Thread [Next in Thread]