Wednesday, March 30, 2016
Figaro is an embedded database library split into four different product editions of the Oracle Berkeley DB XML product:
All of this built out of one single C++/CLI library, which means that, in order to provide the different editions, a lot of pre-processor directives are used in order to set up the builds. This is also true of the supporting libraries (i.e. Figaro.Configuration), not to mention the documentation. And until recently, this was all lovingly built by hand.
This all changed when Microsoft released the latest major update to the Visual Studio build/release management components. I won't bore you with the minutiae, but if you haven't looked at it yet, it's far easier to use, accommodating, and platform-neutral than the MSBuild-based parent product that comes with TFS.
The Figaro.Configuration library (soon to be published to our GitHub page) is designed specifically to leverage the configuration files and build the configured FigaroEnv, XmlManager and Container objects with it. Also included are the factory objects ManagerFactory, ContainerConfigFactory) needed to simplify object construction and get started faster.
I have a confession to make - this library wasn't terribly useful in that initial release. In my haste to get the packages pushed out, it hadn't been thoroughly tested yet. This release fixes several issues found in getting the sample code working. The configuration schemas have been updated to have their own namespace for the edition they represent, and they've been tweaked to make sure they represent the appropriate features correctly.
One thing that needs examining is that, despite being thoroughly documented, the Figaro.Configuration documentation isn't generating in the help file or the website. This is more of a Sandcastle Help File Builder bug/feature that will inevitably get resolved; in the meantime, the Intellisense works, the schemas have documentation in them, and all of the features are documented in great detail in the help file. If you're not sure how to use something, search the CHM or the help website at http://help.bdbxml.net.
An important word about configuration: Make sure your <configSections> section is featured as the first node in your configuration file. If your config file doesn't contain it and is full of other features, it may not place itself up top during the NuGet package install. As a result, you may run into exceptions about configuration not working correctly. Due to limitations in the XDT transformations in NuGet, this isn't going to change on our side as the code we have for it breaks other scenarios, but it's something .NET developers should be aware of in general, so there you go.
Included in the NuGet package is a C# class called FigaroDataManager. As mentioned, this is sample code designed to help developers get started quickly. So far it demonstrates how to:
The Figaro library is tricky and isn't nearly as intuitive to use as your typical NuGet package, so over time this class will probably grow in scope to demonstrate other esoteric features, such as indexing. Inevitably there will be sample projects for consumption that demonstrate things much better; this will be especially prominent once the High Availability edition is released.
The NuGet packages were turned inside out, closely examined, and more carefully packaged. One of the first things you should notice (after the prominently displayed README file) is the FigaroDataManager mentioned above, reading configuration data out of the application configuration and setting itself up for embedded database greatness.
One additional modification was putting the libraries in lib\x86 and lib\x64 instead of something like lib\net40. It doesn't break anything, but one of the things we're looking at in the future is having packages containing both 32 and 64 bit libraries. Depending on the feedback, this may be something we introduce in the future, possibly as a replacement to the existing platform-specific package releases that we have (though most likely as an additional, since switching between one and the other requires some hand-crafted MSBuild work inside one's projects).
All in all, for .NET developers this release should have been the initial one, since it demonstrates its value much better than the initial release did. And with the efforts to automate the build, this release has much more value to the publisher than probably anyone else. The good news is that, now that the release pipeline has been established, new features can start coming out faster.
I've mentioned the High Availability edition for a while now, and I currently have everything in place for it, but the code hasn't been ready and, given the state of the rest of the code, it didn't seem appropriate to work on the new feature while ignoring some pretty obvious issues. Now that this release is out, the goal is to make High Availability the priority for the next batch of NuGet package updates. An embedded XML database engine is revolutionary for .NET developers (despite XML being out of fashion for many), but the High Availability feature is going to be an absolute game changer, especially in distributed client, server, and cloud solution architectures. If you're curious about what it entails, you can get a taste of it here: https://www.oracle.com/technetwork/products/berkeleydb/high-availability-099050.html