Writing a provider based on #liveDB

Topics: Business Logic Layer
Jul 31, 2012 at 4:04 PM

Hi,

We're writing a storage provider for BE based on #livedb (http://livedomain.codeplex.com). #liveDB keeps everything in memory so we are hoping for a significant performance boost.

Unfortunately, a few methods and properties in BlogEngine.Core that need to be called from the provider are marked internal. Also, we added a Serializable attribute to the core entiity classes as our provider uses BinaryFormatter. 

You guys can expect a pull request as soon as we manage to learn mercurial :)

ps. The #liveDB project site is running BE 2.0.0.36 with a custom rolled theme: http://livedb.devrex.se

 

 

 

Coordinator
Aug 1, 2012 at 3:15 PM

Great, let know if you need any help.

Aug 16, 2012 at 9:33 AM

No problems, implementing was pretty straightforward.

We wanted to write the provider in a separate assembly but a few entity classes were internal, also we needed all entities to be marked Serializable. Instead we forked and added our provider directly to the blogengine.core assembly.

We wrote a short blog entry about the provider including some links to the fork.

Not sure about what happens next... Here are some alternative paths:

  • Nothing. The fork lives on independently.
  • We create a pull request and our provider ships with the blogengine core assembly.
  • We maintain the provider in a separate project and create a pull request with necessary changes to the core.

The second alternative would be awesome and I could commit to maintaining the provider. I feel it's up to us to show what kind of value our provider creates before you guys can commit to the extra maintenance involved. 

So I think the third alternative is the best choice, at least for now. What do you think?

Coordinator
Aug 16, 2012 at 3:33 PM

The #3 would probably be the cleanest. We do try to stay as light-weight as possible, not always successful thought :)

Aug 17, 2012 at 8:29 AM

ok, let's do #3 then!

The changes to core are very minor (from internal to public on a handfull of types and a few added SerializableAttribute). It might be less hassle for both parties if you just make the changes directly instead of merging our fork.

Aug 17, 2012 at 8:59 AM

I double checked with @woocode who wrote the provider, and I was wrong about internal types. There were a few internal methods of the provider base class, which are neither called or overridden by our provider so no problem. This leaves only adding a few Serializables. We decided to create a clean fork for the changes to core, making future maintenance easier.