For BlogEngine enthusiasts who like live dangerously and always update their sites with latest code from repository, in the latest build Extension Manager set to use generic data store layer instead of doing it's own thing as it did previously. The story behind it is that in the next release we adding Widgets and customizable Themes, and it makes sense to unify data storage for any kind of "extensions" to avoid headaches in the future. For Extension Manager, it means a bit of redesign. Most of it transparent to the users, but some requires your attention.

If you are using XML blog provider

  • Location of the files has been changed from /app_data/Extensions.xml to /app_data/datastore/extensions
  • Each extension now saves data in it's own file that has the same name as extension class name (ending with ".xml")
  • If you have customized extensions with saved settings, you can update your site and then simply copy saved settings to new locations

If you are using MS SQL blog provider

  • There is a new table added to hold extensions, widgets and themes data:
CREATE TABLE [dbo].[be_DataStoreSettings](
    [ExtensionType] [nvarchar](50) NOT NULL,
    [ExtensionId] [nvarchar](100) NOT NULL,
    [Settings] [varbinary](max) NOT NULL
)
  • Currently, there is no upgrade utility to copy data from old to new table. But it will be available soon.

If you are using MySQL or any custom blog provider

  • Your provider has to override new data store interfaces:
public override Stream LoadFromDataStore(DataStore.ExtensionType exType, string exId);
public override void SaveToDataStore(DataStore.ExtensionType exType, string exId, object settings);
public override void RemoveFromDataStore(DataStore.ExtensionType exType, string exId);
Signature

Related posts

Comments

4/1/2008 12:37:10 AM

Trackback from Chris Blankenship's Ramblings

Convert extensions.xml for new BlogEngine data store

Chris Blankenship's Ramblings

4/1/2008 12:38:57 AM

I wrote a conversion tool to automate the conversion from the old extensions.xml file to an individual xml file for each registered extension. Please have a look!

http://www.dscoduc.com/post/2008/04/Convert-extensionsxml-for-new-BlogEngine-data-store.aspx

Chris

4/1/2008 6:57:22 AM

I was thinking about doing something like it but never got time for it, this is a huge help Chris, thanks a ton! I'll get it tested to make sure it works with final release.

rtur.net

4/1/2008 9:10:30 PM

Please see my issue with the current implementation where the different providers serialize the data in both XML and Binary formats, and don't do the deserialization until they are outside of the provider framework (and make the assumption how the data is serialized based on either being the XML provider or not being the XML provider). Instead of returning a stream from LoadFromDataStore, can we return the original "settings" object that was saved using SaveToDataStore?

Brian Lakstins

4/2/2008 7:45:38 AM

Brian,
I wanted providers to know as little about business objects as possible. This takes burden off from provider implementers. The only exception is XML, this is why I'm checking for it before deserialization.
What exactly is the issue you are running into?

rtur.net

4/2/2008 11:30:51 PM

FYI: Updated conversion tool to allow user to specify a single extension to convert instead of all ManagedExtensions xmlNodes.

http://www.dscoduc.com/post/2008/04/Convert-Extensions-v20.aspx

Chris

4/22/2008 4:05:48 PM

Is possible to use extension manager with a data storage different from the used to storage the post/comments? for example, keep the settings in the xml file and storage the rest of data in mssql storage provider?

cristian

4/22/2008 6:47:19 PM

Cristian, extension manager now uses data store same way all other extensibility components do. That means, it simply passes data to data layer and data layer throw it to data provider. Just out of curiosity, why do you need to keep them separate? We got complaints about inconsistent data storage (some settings stored as XML only) but never other way around Smile

rtur.net

Add comment


 

  Country flag

biuquoteimg
Loading



<<  July 2008  >>
SuMoTuWeThFrSa
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789
Enhanced with Snapshots

Subscribe to Rtur.net