When I first read about CFS a number of months ago and learned that objects are no longer going to be stored in the database, I thought, "What are these guys thinking." I knew that there were going to be problems, and sure enough, there are. The ideal situation stores all objects in the database and the application caches those objects locally on the file system. This is the way that the old system worked for the most part, it just wasn't normallized. The current system is normallized, but they removed the database storage completely. This is something that an enterprise level application should never do.
For one, you are now required to not only backup the database, you now need to backup the IIS Server / file store. By definition the two systems (file store and database) will always be out of sync. Backing up the IIS server is something that just isn't done in most enterprise applications as the application is stored in source control and can easily be rebuild. Think of it this way, if there is a possibility that your site has been hacked, which do you want to use? A backup, or the code in source control? That should be a no brainer.
Since objects are ONLY stored in the file system, you are required to back them up seperately and the store can NEVER be rebuilt. I have a client who upgraded to CS2008 and some of the objects that were in the CS2007.1 database, but had not been cached to the file system, are now not accessable after the upgrade. I am sorry, but this type of change is not at all acceptable for a supposed Enterprise Level application. I can see what Telligent what thinking, but they obviously did not fully think it through, nor did they do their due diligence.
The next version of SQL Server (2008) has totally changed the way that it stores BLOBS (images). This new way of storage makes them available in many different ways and faster to lookup than if they were individual files on the file system. YES, BLOBs on SQL Server 2008 are FASTER than files stored in NTFS (file system). PLUS, they are backed up as a part of the normal SQL Server backup, thus they are always in sync, AND you no longer need a local cache! Yes, you read that last statement correctly, no caching is required to improve performance.
So, the bottom line here is that until CS2008 supports database storage for all objects, I cannot recommend its use to anyone. Stick with CS2007 if you have it and do not upgrade. If you upgrade, there is a very good chance that you will lose quite a few objects just like my client did. Also, the URLs for all objects have changed, which means any existing links to CS2007 or ealier objects would be broken after the upgrade. That in itself could cost you hundreds of hours of lost time to correct on large systems.
Take it easy,
It's been quite a while since I've had much news about CS as I've been working on other projects, but that should be changing for at least the next few months, which is part of the good news. I'm going to be working on a CS related contract and I will also be working on the CS2008 version of the calendar control in my spare time. The not so good news is that I am seriously considering the option of not upgrading any of my CS sites to CS2008, though I do have one internal CS2008 site for development purposes.
The project that I will be working on is using CS2007 and the customer has made a firm decision to not move to CS2008. The major reason that I and others are considering this is because upgrading to CS2008 is a major undertaking and it is also a major change from the original direction of CS. Performance issues aside (as they can be worked out), CS 2008 doesn't feel like a full product release. It feels more like a stepping stone to an unknown future. The current licensing model has made it impossible for small businesses and some mid-sized businesses to afford CS, and if I upgrade this site to CS2008, I will no longer have the .NET Community license that I have with CS2007. I would be in direct violation of the current CS2008 license.
What does this mean to you? Well, it means that this next release of the calendar control may be the last. The initial release may have more bugs than usual as I'll be the only tester prior to it being released, and bug fixes may take longer to find and fix. I have a feeling that Telligent is going to add some sort of calendar functionality to CS in the not to distant future, so this may only be a short lived issue, though there will definitely need to be some sort of conversion from this control to whatever Telligent may provide. As things progress, I'll try to keep everyone up-to-date.
My next blog post will cover how I am using TFS to manage multiple branches of CS and how it makes it easier to selectively merge SDK updates into these branches. TFS has 2 way merging, which means that you can merge up to the root (inverted tree) or down to any branch while only affecting the 2 branches that are being merged. Source control covers only about 25-30% of what TFS is as it is an Application Lifecycle Management (ALM) application that covers builds, documentation, testing, tracking, and a lot more.
Take it easy,