Monday, 25 October 2010
A snapshot of his presentation can be found on his blog, but for me the most enlighten point was the battle between reindexing a table and shrinking a database. Typically the two feel like they should go hand in hand, but they will in fact fight each other. Re-indexing a table will create a new copy of the table in question, with the data correctly ordered to reduce fragmentation. As the original data is just marked as available, the process of re-indexing a table will potentially result in a database growing by the size of the table being re-indexed. Once the re-index process has completed the database will report all the space taken by the old copy of the table as free space.
However, if at this point if you shrink the database you will refragment your nicely re-indexed table as the shrinking process reads/moves the last row of the table first. This means your table content will end up reversed (and totally fragmented) after a shrink comand.
There are many reasons why you shouldn't shrink your database, this being just one of them!
Thursday, 14 October 2010
By default objects mocked using MOQ will handle calls to method / properties that have not been defined, which 99% of the time will be the desired behaviour. Occasionally however a situation will require that MOQ throws an exception when accessing a undefined method or property. The MOQ framework provides this functionality via the MockBehavior enum but this can only be set during the construction of the mocked object. Typically this won’t cause any problems as the mocked objects are created inline but we’ve just encountered a scenario that needed a little lateral thinking as for reusability we have objects that inherit from Mock<>. These mocked objects already had constructor parameters which (in the short term) we didn’t wish to change so to get around this we created a static property on the mocked object that is then used to inject into the base MOQ constructor.
Note: Being a static property it does mean that we have to remember to reset the value after constructing the instance in question, but in the short term it did resolve the issue of how to change the MockBehaviour without modifying the mocked objects constructor.