377845 - Decouple calendar manager from storage provider

Status: RESOLVED FIXED

(Calendar :: Internal Components, enhancement)

Description

[Daniel Boelzle [:dbo]]

IMO it's a mess that the calendar management code is tied to the storage provider's schema, i.e. checking/relying on its schema version.
Effect is that it's currently not possible to register a provider (!=storage) unless at least once a storage calendar has been created. This hinders any auto configuration attempts.

IMO the calendar management code should use an own schema version.

Comment 1

[Matthew (lilmatt) Willis]

+1

When I was doing various SQL schema updates and the "schema too new" error dialog, it seemed wrong to me that both the calendar manager/properties and the storage provider used the same schema version row.

This needs to be changed.

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

We might even want to reconsider if storing calendar properties in the database is the right way. It seems more logical (at least to me) to store them as preferences.
mailnews does that, and it seems to work ok there.

Comment 3

[Daniel Boelzle [:dbo]]

(In reply to comment #2)
Related is bug 378754 (calendar auto config) which would possibly be obsolete if we configure calendars via prefs.

Comment 4

[Daniel Boelzle [:dbo]]

I think we should first judge on pref based calendar registration (bug 403006), then this bug would be obsolete.

Comment 5

[Daniel Boelzle [:dbo]]

fixed with bug 403006.

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".