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);
Share/Save/Bookmark
Signature

Comments

4/1/2008 8:37:10 AM #

trackback

Trackback from Chris Blankenship's Ramblings

Convert extensions.xml for new BlogEngine data store

Chris Blankenship's Ramblings |

4/1/2008 8:38:57 AM #

Chris

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 2:57:22 PM #

rtur.net

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/2/2008 5:10:30 AM #

Brian Lakstins

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 3:45:38 PM #

rtur.net

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/3/2008 7:30:51 AM #

Chris

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/23/2008 12:05:48 AM #

cristian

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/23/2008 2:47:19 AM #

rtur.net

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 |

Comments are closed
<<  March 2010  >>
SuMoTuWeThFrSa
28123456
78910111213
14151617181920
21222324252627
28293031123
45678910
Enhanced with Snapshots

Subscribe to Rtur.net