you would think I would have learned...
Ray Kiddy
I wanted to see how to, possibly, help code a suggestion I had in
Calendar. So, I checked it out, built it and ran it.
It upgraded my schema, had some error, and now all my local events are
not visible. I can launch the old version and it shows no days in the
month, just a big empty box. And the local events are gone.
I actually thought upgrading might not delete my data! Really, after
poking that particular pencil in my eye this many times, I just have to
laugh.
- ray
Mike
I have to give you kudos for attempting whatever it was. If I tried,
my computer would burst into flames....
Michiel van Leeuwen
>
> I wanted to see how to, possibly, help code a suggestion I had in
> Calendar. So, I checked it out, built it and ran it.
>
> It upgraded my schema, had some error, and now all my local events are
> not visible. I can launch the old version and it shows no days in the
> month, just a big empty box. And the local events are gone.
As far as I know, there is no automatic way to revert to an old schema.
I'm not sure how that would work, because a schema upgrade usually adds
data. Reverting would mean that the new data is lost.
But with the right sql commands and a sqlite tool, it should be possible
to revert manually. In this case, the amount of work it would be depends
on the number of different timezones your events are in. The schema
upgrade renamed the timezone identifiers, so the downgrade should revert
to the old name.
Do you happen to know if you have used many different timezones? And are
you comfortable with sql queries?
And I think that, in order to prevent this in the future, any schema
upgrade should make backup of the database first. But that won't help
you now...
Michiel
Daniel Boelzle
Michiel van Leeuwen wrote:
...
> And I think that, in order to prevent this in the future, any schema
> upgrade should make backup of the database first. But that won't help
> you now...
I am not sure about this, I'd rather prefer to rely on database
transactions like we do in the upgrade code. They should sufficiently
prevent this. I think the problem Ray faces is more that wrong schema
versions are in play, i.e. a plain bug in the nightlies. Making backups
only to to revert from malicious nightly builds looks wrong to me. I
think we just need to stress that people shouldn't use nightlies for
production use.
my 2cts, regards,
Daniel
Eric Valette
That kind of advise would be fine if you condescent to fix bug in stable
releases that render lightning nearly unuseable in a timely manner:
- on one hand you say, this critical bug is already fixed => use the
nightly build
- on the other you say do not use it for production!
-- eric
Ray Kiddy
> Ray Kiddy wrote:
>>
>> I wanted to see how to, possibly, help code a suggestion I had in
>> Calendar. So, I checked it out, built it and ran it.
>>
>> It upgraded my schema, had some error, and now all my local events are
>> not visible. I can launch the old version and it shows no days in the
>> month, just a big empty box. And the local events are gone.
>
> As far as I know, there is no automatic way to revert to an old schema.
> I'm not sure how that would work, because a schema upgrade usually adds
> data. Reverting would mean that the new data is lost.
> But with the right sql commands and a sqlite tool, it should be possible
> to revert manually. In this case, the amount of work it would be depends
> on the number of different timezones your events are in. The schema
> upgrade renamed the timezone identifiers, so the downgrade should revert
> to the old name.
> Do you happen to know if you have used many different timezones? And are
> you comfortable with sql queries?
Actually, yo hablo database very well, so I will look at doing that.
I'll probably be able to figure out what the name of the old file was
and where to pull it from. We'll see. If you want to speak up with more
specific info that may not be obvious, please do, but if not, no worries.
> And I think that, in order to prevent this in the future, any schema
> upgrade should make backup of the database first. But that won't help
> you now...
>
> Michiel
Well, and this also tells me that I need to get up off my posterior and
actually write an extension that I had thunk up. Imagine an extension
that, on a schedule, exports copies of your calendars to a known
location. It would almost be like, you know, an automatic backup. Cool, yes?
And part of my griping is due to the fact that I know I should have made
a backup. I just did the build and launch without thinking it through.
One does not expect data-loss bugs, but I know they do happen.
Actually.... So, bug # 437622 bug is a data-loss bug, isn't it? You guys
do not usually leave data-loss bugs as 'UNCO' and severity=normal, do
you? Or am I misunderstanding that bug?
cheers - ray
Bas van den Bosch
(con't know wether you were being sarcastic :-)
gr
Bas
Ray Kiddy
Well, darn it. I should have known that a good idea like that would not
just lying around. Somebody already did it. O well.
Thanks for the heads up and I'll RTFS (as in R T F site) next time.
- ray
Barry Edwin Gilmour
Calendar/0.6a1
Many thanks Bas. Nice to have both ICS and HTML options. Barry
Michiel van Leeuwen
> Actually, yo hablo database very well, so I will look at doing that.
> I'll probably be able to figure out what the name of the old file was
> and where to pull it from. We'll see. If you want to speak up with more
> specific info that may not be obvious, please do, but if not, no worries.
I can point you to the code that does the upgrade. The downgrade would
be the reverse.
There are two parts. part one:
http://mxr.mozilla.org/seamonkey/source/calendar/base/src/calCalendarManager.js#322
All you need to do there is remove the table
part two:
http://mxr.mozilla.org/seamonkey/source/calendar/providers/storage/calStorageCalendar.js#1128
That's less easy. It translates the timezone names in a lot of tables.
If your events are in just one (or a few) timezones, you can use a query
to put back the old timezone name. The old name looks like:
/mozilla.org/20070129_1/Europe/Amsterdam
(hoping I got the date part right. If somebody knows better, please tell
me!)
New timezones will just got the continent and city parts.
You also need to update the schema version, which is stored in the table
cal_calendar_schema_version.
Actually, you can start by only changing the schema versions. You should
at least get some data now, although the events are likely to be off by
a few hours. But it's a got first test.
And don't forget to backup the database file first!
Michiel
Stefan Sitter
> Bas van den Bosch wrote:
>> https://addons.mozilla.org/en-US/sunbird/addon/3740 ?
If you want to create a backup ensure that you choose the iCalendar
(ICS) format. HTML and CSV can't be used to restore/import a calendar.
Stefan Sitter
> That kind of advise would be fine if you condescent to fix bug in
> stable releases that render lightning nearly unuseable in a
> timely manner:
> - on one hand you say, this critical bug is already fixed => use
> the nightly build
> - on the other you say do not use it for production!
Nobody recommends a nightly test build for production, at least I
hope so. It happens that developers ask bug reporter or commenter to
_test_ with a nightly build to check if a specific issue is
still reproducible or fixed. Do you think there should be e.g. a
wiki page created that contains information on how to set up a test
profile etc.?
I don't know what failure your are referring to. But it indicates
that nobody tested Lightning 0.8 Release Candidate 1 or Lightning
0.8 Release Candidate 2 with that special workflow or setup. If
there exists a bug report for this issue I'd recommend that you set
the in‑litmus flag to ? to request the creation of a test case on
<litmus.mozilla.org>.
/Stefan
Eric Valette
> <litmus.mozilla.org>.
Come on! One of the bug was open for 5 month before 0.8 release
(ITIP/IMIP support), was flagged blocking 4 weeks before final release
and then 0.8 was released! Many people have complained before the release.
You have at least two bugs open for 0.8 that makes it hardly unusable
1) interoperability with outlook 2003 (cancel, tentative,...)
2) inability to subscribe to event send via mailing lists. As far as I
remember RC2 did not contain the bug because it was introduced trying to
fix the first one!
And you know this perfectly. So your mail is either alzeimer effect or
pure disinformation!
-- eric
Eric Valette
> You have at least two bugs open for 0.8 that makes it hardly unusable
> remember RC2 did not contain the bug because it was introduced trying to
> fix the first one!
>
> And you know this perfectly. So your mail is either alzeimer effect or
> pure disinformation!
>
> -- eric
Bug 1 is Bug 361635
Bug 2 is BUG 428274
Btw is looks like the bug 428274/428392 is taking the same path as
361635 and will probably not be fixed for 0.9 ;-)
-- eric