Back in 2010 at the first Dreamcore conference, I was honored to present on two topics: ”Data Retrieval Techniques with Sitecore” 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:1. Much richer out of the box:
a. one can specify locations, templates, etc.2. More extensible, more flexible and “overridable”
b. indexes all fields
c. supports tagging
d. automatic prioritization
a. Configuration is separated from database3. 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.
Convinced yet?
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.
1. All the good stuff about the “new” search listed above.
2. There is already a very comprehensive document on the “new” search on SDN. It should explain most of what the “new” search is about.
3. There is a shared source project called “Advanced Database Crawler” which leverages the “new” search and pushes its limits further introducing such things as field filters, dynamically computed fields, extended field crawler factory, plus includes an easy to use Searcher APIs that should abstract complexities of building search queries.
4. I have also blogged about it and recorded a very long and boring screencast showcasing this component.
5. Ivan blogged about it for quite a bit here and showed a few code snippets and workarounds.
6. 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.
7. 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.
8. 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.
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 Sitecore CMS versions if you go with it:
- 6.4.1 rev.101221
- 6.3.1 rev.110112
- 6.2.0 rev.101105 (Update-5)
- 6.4.1 rev.101221
- 6.3.1 rev.110112
- 6.2.0 rev.101105 (Update-5)
They all contain some critical enhancements that will make your experience with the “new” search much smoother.
Enjoy it!
13 comments:
Great post, thank you so much, I used the "Lucene Search Module" from the "Shared Source Library" in a couple of projects but I had to tweak it a little bit to fit my needs, but I didn't know that there was an "Old" way and a "New" way of handling Lucene through sitecore APIs so I will try to study the document mentioned and make my own custom module built over the "Lucene Search Module" I already have, using the correct approuch :)
Hi Alex, where we can see you demo about new search ?
Hi Alex ,
Where we can see you demo about new search ? Do you have some videos ?
Kind regards .
hello,
You can check out this post, where I show what you can build with the new search:
http://sitecoreblog.alexshyba.com/2010/11/sitecore-searcher-and-advanced-database.html
Hi Alex,
I'm using similar code to what's in your slides, and have found that
resultCollection = hits.FetchResults(0, hits.Length);
returns different versions of the items that I am searching for. Is there any way to make it just return the latest versions of the items?
At the moment I'm just looping through all of the hits, and using the ones that are the latest versions... and I'm hoping there's a better way to do it.
It feels that you need to be searching/indexing the web database rather than master. The web db contains only the latest version.
Also, check out the Searcher.RunQuery() method here: http://trac.sitecore.net/AdvancedDatabaseCrawler/browser/Trunk/Searcher.cs
It contains item fetching logic that accepts a flag (showAllVersions) or not.
Ahhhh, that was it. I'm using my master db on my dev box....
Works perfectly with the web database.
Thanks Alex.
I love the module but can you tell me if there is a support/discussion thread for it? I just got denied by Sitecore Support when posting a ticket around items not being crawled after being published and I keep having to run the RebuildDabaseCrawlers.aspx. They state that because it is a Shared Module it is not under the Support Agreement.
James - we need to narrow down your problem. If your index is not getting rebuilt, this is standard Sitecore functionality, thus covered by support.
If you have a problem with a feature of the Advanced Database Crawler, you can ask me here or post it on the shared source forum on SDN here: http://sdn.sitecore.net/forum//ShowForum.aspx?ForumID=20
now that I am typing it, I realize you just posted a question there...
James: I just responded here http://sdn.sitecore.net/forum/ShowPost.aspx?PostID=34328
Hi Alex,
One reason I was reluctant to move to the "new" search was to do with the lack of an OOTB index rebuild tool. The "old" indexes can be rebuilt using the control panel > database > rebuild index tool, but this tool will only build the "new" system index and not any custom indexes. Is there a tool I've missed or are we expected to handling our own index rebuilding, as you did with the advanced DB crawler?
Alex, did you answer Alistair?
I think that the missing/insufficient tools for updating/rebuilding the new indexes is a big big problem.
The Index Viewer tool is lacking basic functionality and developers seldom have the time to develop their own indexing tool.
Hi Alax,
I did upgrade the sitecore version 6.2-2 to 6.3 101029 and index search stop work, and I ask for help from sitecore support Team, meanwhile I read your blog and Its realy work, I upgrade till 6.3.1 and My problem was gone.
Thanks..
Regards
Dipak
Post a Comment