Sitecore Buckets and Improving bulk import speed

Hello.

I ran into a problem while trying to bulk insert items into a bucket in code, using the Glass Mapper SitecoreService - insert speed was very slow (10,000 items took 50 minutes). Deleting all items from the bucket was also fairly slow.

The solution in code is basically the same as the Powershell equivalent in the link above: -

            using (new Sitecore.Data.BulkUpdateContext())
            using (new SecurityDisabler()) // yes yes I know

            {
                foreach (var item in data)
                {
                    sitecoreService.Create(folderItem, item, false, true);
                }
            }

Yes I know I should be using a UserSwitcher instead of disabling all security..

Total import time down from 90 minutes to 6. Not bad :)

StructureMap usefulness

Yet again I find myself spending literally minutes of my life trying to figure out why something is going wrong, only to find a useful feature of something that could potentially save many more minutes; time better spent writing unit tests, for example, or lolling around the coffee shop talking about stuff.

Turns out in the end I'd configured the wrong repository name. Dumbass mistake of the kind we all make from time to time, but one of those cases where the wood is clouding the view of the trees in the way woods always seem to.

I'd done this ..

instead of this..

Note "EmployeeRepository" instead of "LookupRepository". For clarification, LookupRepository wasn't yet finished.

Upon trying to resolve a reference to IEmployeeService, StructureMap was throwing Exception code 202 - "No Default Instance defined for PluginFamily IEmployeeRepository". Confusing at first, turns out I was of course staring at the obvious problem all along.

Trying to replicate this was a pain as it was a case of fire up unit test; get to point that fails; fail (repeat).

Now I'm sure you've come across the ObjectFactory's "WhatDoIHave" method - which dumps out the state of the container, and what resolves to what. It's a useful way of pinpointing anything that doesn't have a concrete type defined for resolution. However, this chap is even more useful: -

Rather than having to get to the GetInstance method of StructureMap to find out you have a configuration problem, you can instead call this after ObjectFactory.Initialize, and it'll run through the map and attempt to construct everything it can.

I wouldn't recommend this for production release, but while in build it could save you at least one cup of coffee. And that's a good thing.

StructureMap is great. So much nicer to use than Unity. Feeling the love :o)