Back in 2010 at the first conference, I was honored to present on two topics: ”” and “Using Lucene.NET with Sitecore
If you have not seen any of those, download the slides and check them out. I consider myself being a data guy, so that’s why I really enjoyed presenting on these topics. Not sure why, but I love everything about data access, and absolutely adore what Microsoft did with Entity Framework 4, especially the oData stuff. There is something truly exciting in seeing your data flow and materialize in one shape or another.
Anyways, back to the topic. During my presentation on Lucene/Sitecore marriage, I was showing that Sitecore actually has two (!!!) implementation of Lucene.NET. One is a legacy, what we call “old” search. Everything within Sitecore.Data.Indexing namespace is considered to be “old” search. It is configured and implemented differently, though it uses the same Lucene.NET dll. There is also the “new” search which is represented by a few classes within Sitecore.Search namespace.
The main point of the presentation was to show that you should not really use the “old” search if you develop on Sitecore 6.
Here are some extracts from the presentation explaining why:
- Much richer out of the box:
a. one can specify locations, templates, etc. b. indexes all fields c. supports tagging d. automatic prioritization 2. More extensible, more flexible and “overridable”
a. Configuration is separated from database 3. Better API
a. enforcing programming best practices b. friendlier and easier to work with c. external integration is possible d. supports of “context of search operation“ 4. Faster and more dependable.
Both “old” and “new” search index are being maintained by Sitecore in a similar fashion. However, they present different APIs to interact with them.
There is got to be a reason, but I frequently witness Sitecore implementers favor “old” over the “new” one. My only explanation is that we did not fully document the “new” search with the release of Sitecore 6, and that SDN was not steering developers in the right direction.
My humble hope is to address this shortcoming.
Here are 8 reasons why I should consider using “new” search.
All the good stuff about the “new” search listed above.
There is already a very comprehensive document
I have also blogged about it
Ivan blogged about it for quite a bit here
The “new” Sitecore.Search namespace has a high chance of being the data access technique of choice, since that’s all you need to effectively query Sitecore data repository.
The “old” implementation _may _be deprecated in next major release, so it is important not to miss the early opportunity and migrate as soon as you can.
It is tried out in production by many already.
Just recently I actually was able to help a partner who decided to completely revamp their Sitecore Query based data access implementation with the “new” search. The results were reportedly dramatic and are already paying off.
One important note: please make sure to use either of the following versions if you go with it: - 6.4.1 rev.101221 - 6.3.1 rev.110112 Sitecore CMS