I've reviewed all of the release notes and we've been doing testing to see if solrj that came with solr 3.5 would work with solr server 4.2.1. We are not using any of the new features of 4.2.1...we upgraded purely for the improved performance and much smaller memory footprint of the indexes. While I have not identified anything in the release notes that looks like a deal breaker, I also realize that the powers that be may be thinking that this is such a no brainer question (why would ANYONE want to use solrj 3.5 with solr 4.2.1) that it simply was assumed obvious and did not need stating.
Well, we have a unique business/technical case that involves other applications, other platforms, timing and resource constraints, etc. Since we've noticed that in the simple search cases solrj 3.5 DOES work with solr 4.2.1 (obviously the new features do not...but we are not using the new features) we've opted to investigate this further. However, if anyone knows definitively that this WON'T work I'd appreciate a heads-up on it as you could save us a lot of time. Since I know someone is going to ask "why do you want to do that"...I'll state up front that we DON'T want to do that. Unfortunately we live in a non-perfect world and we have some very specific (if not weird) project and technical constraints that could be temporarily mitigated if we could get this to work for a short period of time. Because the nature of these constraints are so project-specific (and somewhat involved), I won't be going into any details here. We are well aware of the fact that this would be a sub-optimal solution...but it turns out to be worth our time to at least investigate it as a stop-gap measure. If you have any information regarding whether or not this might work (as in "yeah, we did that and it worked okay"...or..."no, that won't work because protocol XYZ changed between versions and <yada,yada,yada>") I would appreciate it. As stated above, simple cases using both exact match and analyzed fields have been shown to work. We are already investigating the more involved cases, but I figured it wouldn't hurt to ask for the input of the solr community. With much appreciation, Peter S. Lee Software Development Lead ProQuest 789 E. Eisenhower Parkway Ann Arbor, MI, 48106-1346 USA 734-761-4700 x72025 peter....@proquest.com www.proquest.com ProQuest...Start here InformationWeek 500 Top Innovator<http://www.proquest.com/en-US/aboutus/pressroom/09/20090922.shtml>
