Open peab0dy opened 10 years ago
+1 Upgraded our 6.5 solution to 7 but I cannot get the search functionality to work. I had to make some minor changes to QueryRunner class to get it to compile against Sitecore 7 assemblies. All I'm getting at this stage is StackOverflowExceptions as soon as I try to use any search functionality from the front-end.
hello,
have you guys had any luck with this? We migrated from sitecore 6.6. to 7 and the library is crashing and I ma not being lucky enough to fix it... thanks, Mariella.
Guys,
Your best bet in moving to Sitecore 7 is to move away from scSearchContrib, and use the new Sitecore 7 indexes and the Sitecore.ContentSearch API. I don't think you are going to see anyone going through the effort to make this library work on 7, because it's totally unnecessary.
Nick
...in other words, you only need to spend about 100 hours rewriting your code...that's all! :P I decided to forgo the huge re-coding effort and go to 6.6, which gives you just about everything that's in 7. There are just some minor tweaks that need to be made to scSearchContrib which basically just involve writing a few lines in a different way (VS will point out these issues). Just be cautious if you use RangeQuery because that may work differently than expected with 6.6 (Lucene 2.9.4.1).
Thanks, after a lot of sef-denial yesterday, I came to that conclusion as well. I will have to re-write the search component of my company's site if we want to use 7 to be better off in the future.. I guess, I can't give up on coffee just yet.
I actually managed to make it work with a few modifications. I can check what exactly I did next week. We have a whole project written around this module so re-writing everything to use native functions now available in Sitecore 7 would be a huge amount of work.
Thank You Kaalen, if you can I will be thankfull.
Hello,
I have published this branch with some sample code showing how SearchParam and FieldSearchParam can easily be converted to Linq that works with 7.0. I've removed unnecessary projects and reduced the noise within QueryRunner class to simplify things. So here is what I had to do:
Even with this quick and dirty approach, the limited set of the demo pages seem to work on 7.0U4 as expected.
A few notes.
Please use the code in this branch solely to correlate ADC searching APIs to ContentSearch APIs in Sitecore 7.
Hope this helps.
Trying to wrap my head around the value full 7.0 compatibility could bring. None of the new UIs would work, none of the goodies we built for ContentSearch under the hood either. You will end up with 2 flavors of search, which means more overhead, more complexity. Somebody mentioned 100 hours of effort to convert the code using ADC to 7.0 API. What exactly does this effort include - pure code migration?
Here is the way I see the 7.0 migration process, please correct me if I am wrong.
To start with, the project consist of the Crawler and Searcher as main components.
The Crawler pretty much extends the 6.x search crawler. In 7.0 we have these features out of the box in default configuration. The config syntax is quite similar. If you have any ADC dynamic fields, they became Computed Fields in 7.0. Most of the other configuration was to make date fields indexed properly, which is already handled for you in 7.0. Bottom line is that if you haven't customized your Crawler, you should be able to pretty much use the default indexes in Sitecore 7.0.
The Searcher piece is obviously obsolete now. Basically, what you need to do is convert your SearchParams to Linq expressions. Since Linq is way more expressive and flexible than the Searcher implementation, it should be pretty straightforward to convert this piece. Things like paging are native.
If anyone cares, here is my reasoning behind drawling the line in the sand and not supporting 7.0:
It's not that simple in the real world... we have a project developed on top of this module extending the crawler and custom fields etc. Quick look at the project tells me it contains close to 210 code files. Configuration include file for indexes alone has close to 1500 lines. Redeveloping all that with Sitecore 7 API is obviously quite a lot of coding work, then add complete testing on top of that and we're talking about a significant amount of work involving more than one resource.
Meanwhile our business users are asking us if we can upgrade to the latest version of Sitecore so that the backend UI would work with the browser that ships with their SOE (win7 & IE10) and a whole bunch of other things. So there are reasons why we would like to upgrade to Sitecore 7 but the need for complete redevelopment of a major component in our solution because of lack of compatibility is obviously a pretty big obstacle. We need a solution to ease this transition.
I forked to kaalen/SitecoreSearchContrib and the code which compiles against Sitecore 7 is in the 70compatibility branch. As far as I remember I didn't have to do any other configuration changes and all the functionality which depends on lucene appears to work okay on the front-end
I echo what kaalen said about the redevelopment effort. Our entire site is built on top of the search logic, so the effort is akin to redeveloping our entire site. I was conservative with the 100 hours of effort, because a partner estimated 4-6 weeks of effort. I spent 2 weeks, just getting the search logic working with 6.6 from 6.4.1. Our management was sold on an easy upgrade path and less coding with Sitecore. Unfortunately, the opposite has been true, so it's not easy to justify a month and a half just to upgrade. To be fair, it could be the way our site was implemented, but we did use a Sitecore implementer.
Alex, I appreciate your advice and all the work you've done on the SearchContrib! Not faulting you. We have to get on Sitecore 7 at some point, so maybe it's better to ween us off sooner than later. The reality is that the redevelopment effort will hold us back from 7, probably for another year, at least.
Just throwing this out there... What if the scSearchContrib query/search classes were updated to use Sitecore.ContentSearch APIs itself (e.g. PedicateBuilder). Then the upgrade effort would just be changing any custom Dynamic Fields to Computed fields, and you could utilize the new search indexes without needing to rewrite query logic?
This is an interesting discussion... I do see your guys point of view on the re-code, but I do see Alex S.'s point of view on just going forward with 7. I started the re-write of my code... and while trying a few things and reading the documentation a bit here and there I could see that on a long run, we will be in a better place. Alex, I got stuck with the configurations in the Web.config and Sitecore.Buckets.config. I am not sure anymore if the indexes need to me move and what to use to substitute the crawlers references in the web.config...
Thanks, Mariella.
Can anyone migrated the code which works with 7.1? If yes please share it with as am facing big trouble to migrate.
I used @sitecorian and @kaalen code to create these dlls which works great in my Sitecore 7 project. Hopefully this helps someone. Just replace the old dlls with the ones here and update your imported namespaces accordingly. https://github.com/ashokry/SitecoreSearchContrib7
You mentioned "you won't need the code from this project at all as different bits are natively available in Sitecore 7.0". Can you provide any direction or point me to docs on how to migrate?