Re: [Mailman-Developers] GSOC:Populating two default styles
![](https://secure.gravatar.com/avatar/173371753ea2206b9934a9be1bdce423.jpg?s=120&d=mm&r=g)
On Jun 24, 2016, at 03:14 AM, Harshit Bansal wrote:
I was trying to populate the two default styles in the database. For this purpose, I was trying to use ConfigurationUpdatedEvent as used in the earlier style manager but I am recieving following error: [...] AttributeError: No section or category named db.
It seems that the database layer hasn't got initialized by the time this event was fired. Is there any way of fixing this or any other way using which I can populate the database when mailman starts?
That's right.
Getting the initialization sequence correct is pretty tricky, and it's true that the configuration subsystem is initialized before the database connection is created. If you think about it, it has to be this way since there are settings in the config files that control how the database is set up.
What I think this means for you is that you can't use the ConfigurationUpdatedEvent to set up your stylets until the database is set up. Unfortunately, right now there aren't any events fired when initialization is completely, but just the other day Aurelien and I sketched out an event-based plugin mechanism for better HK integration, and one of the things I realized we needed was some additional event notification for the various stages of initialization.
Right now, your best hope is to use the [mailman]post_hook which gets run during initialize_3() and is guaranteed to be run after both the configuration subsystem and the database connection is set up. Eventually the pre_hook and post_hook will be deprecated because they aren't really set up well for plugins, and we'll have events for the various phases of initialization, so you could register a handler for one of those events.
If you decide to keep the ConfigurationUpdatedEvent handler (e.g. because you want to do other stylet things if the configuration changes once the system is up and running), just check for the existence of the config.db attribute, or catch the AttributeError. If the attribute is missing, you know the ConfigurationUpdatedEvent is too early for your purposes.
Hope that helps. -Barry
participants (1)
-
Barry Warsaw