Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
To offer more flexibility in displaying search results, a way of presenting apachesolr search results with the Views front-end should be provided.
How this can be accomplished best (in terms of usability, performance and abstraction) has yet to be determined. In any case, I plan to have this done by the end of Jule.
Two ideas up to now:
- Implementing the Solr search as a Views filter, which would certainly function, but probably not perform very well.
- Using just the Views front-end and feeding it with data from the Solr searches. It remains to be evaluated to what extent this would introduce unnecessary dependencies and if it could be made abstract enough to aid others in integrating other search engines.
Any comments or suggestions would be appreciated.
(Note: This will most probably build on the drupal 6 version of this module, since Views 1.x doesn't offer enough possibilities.)
Comment | File | Size | Author |
---|---|---|---|
#97 | current-query-fix-254565-97.patch | 2 KB | pwolanin |
#95 | current-query-fix-254565-95.patch | 2 KB | pwolanin |
#92 | clone.patch | 384 bytes | mkalkbrenner |
#90 | apachesolr_cache.patch | 1.2 KB | Scott Reynolds |
#87 | views-254565-87.patch | 20.56 KB | pwolanin |
Comments
Comment #1
jayjaydluffy CreditAttribution: jayjaydluffy commentedyeah this is what I've been looking for...Anyone can help us here..Thanks
Comment #2
arman CreditAttribution: arman commentedIs there anyway people can assist with this effort -- test -- code -- architecture?
Comment #3
drunken monkeyWell, ideas on how to do it are always appreciated, if you know your ropes with Views.
Apart from that it would also be great if you could test the prototype(s), once I finish one. Of course, I'll post here as soon as that is the case.
Comment #4
drunken monkeyOK, the first prototype is done. The attached patch adds a file includes/apachesolr.views.inc, which should add an apachesolr filter to the Node base table and a block view that utilizes that filter.
The work is done in views_handler_filter_apachesolr_query::query(), where a where clause is added to the views query according to the current search result. The nids of the documents returned by apachesolr_static_response_cache() are added to a list which is then used as "AND node.nid IN ($list)". If no results were found (either because there was no search, or the because the search yielded no results), "AND 0 = 1" is used instead, so no nodes are shown at all. The approach is rather slow, because it uses a db query in addition to the Solr query, and it sadly only works on the search result page, but it's at least a working prototype as a base for improvement.
To test, simply apply the patch and go to Administer > Site building > Blocks. There, move the "ApacheSolr: Search results" block to "Content" (or any other section you prefer) and maybe also configure it to be only displayed at "search/apachesolr_search/*" (for performance reasons). You could also deactivate the "ApacheSolr: Sort" block, because it will be useless for the view.
That's it, if you now do a normal Apache Solr search the view should be displayed beneath the normal display of search results.
I chose a table for output, to easily distinguish it from the normal search results, but of course it can be altered just like any other Node view at admin/build/views/edit/apachesolr_search_result.
Comment #5
robertDouglass CreditAttribution: robertDouglass commentedyou should try an alternate approach and see if speed is better. Try running the views query first, getting the set of nids, and then sending that to solr as nid:1,4,65,777,899 etc.
Comment #6
robertDouglass CreditAttribution: robertDouglass commentedPS make sure and benchmark it somehow so you know which approach is actually faster.
Comment #7
drunken monkeyHm, don't know if that's possible without Views hacks. As it seems to me, after the query has been executed there is no way to retrieve, let alone alter, the results before they are rendered.
But as said, the documentation is far from completed, and I'm mostly just searching the code, at the moment. So maybe there is a way, we'll see.
Comment #8
robertDouglass CreditAttribution: robertDouglass commentedPlease feel free to open a support request in the views issue queue, or ask in the views developers group on g.d.o. Earl and the team are very helpful to developers writing Views support modules, and this one is a very interesting case that might have ramifications for other integration modules.
Comment #9
drunken monkeyFYI: From now on, the prototype's current version can be found in the module's HEAD.
Of course, I'll keep posting here whenever there was a big step from the last version.
Comment #10
drunken monkeyAs required by the SoC rules, attached is a snapshot of the current state of the development.
There have been some minor additions compared to the patch I posted here - most notably facets now work with the view, too.
But there is still no prototype that feeds a view completely with Solr results, without the detour via the database query.
Comment #11
drunken monkeyForgot to mention: a public demo site is now available at http://soc2008.hotdrupal.com/~dmonkey/drupal6/.
Check it out, if you want to!
Comment #12
jayjaydluffy CreditAttribution: jayjaydluffy commentedI guess this is it just good for views 2 D5. Nice job!
Comment #13
drunken monkeyHEAD contains now a functioning version of the second prototype. You just have to apply the patch to a current check-out of Views and you should be able to select a new base table, "Apache Solr", when creating a view.
The argument doesn't work, yet, but the basic functionality is there.
Comment #14
drunken monkeyThe version in HEAD is now working very well. There are still some minor flaws, but no real bugs are known.
Also, attached is a downloadable version of the module. This doesn't contain some changes made to the DRUPAL6--1 branch in the last months, so to really use it you should rather wait until we merge this with the main branch. Which will, hopefully, be pretty soon.
Comment #15
drunken monkeyThe attached patch merges the current status of HEAD into the normal D6 branch. Afaict everything works normally with it.
Comment #16
robertDouglass CreditAttribution: robertDouglass commentedComment #17
robertDouglass CreditAttribution: robertDouglass commentedcritical = blocking issue for 1.0 release.
Comment #18
janusman CreditAttribution: janusman commentedHmm, how about an actual patch to test? Or is the patch from http://drupal.org/node/254565#comment-900025 still valid?
Thanks!
Comment #19
drunken monkeyWhat about the one at #15?
Comment #20
janusman CreditAttribution: janusman commentedHmm... that patch is 74kB! Could you reduce it to patch *just* what you are trying to patch? =)
If HEAD is somehow out of sync with the DRUPAL-6--1 branch (is it?) then please patch against the DRUPAL-6--1 branch...
Comment #21
drunken monkeyDid you even look at the patch?
Most of it just adds three new files, so of course they have to be contained in it. Please just apply it and test if everything works as before.
If you also want to test the new functionality, you'll additionally have to apply the patch in the contrib/apache_views directory to your views module, but this shouldn't be necessary.
Comment #22
janusman CreditAttribution: janusman commentedHmm... I did look at it, but I admit that my previous comment was because I *just* saw a bunch of stuff at the top that's not really views-related. I think that we should handle code simplification seaparately from this patch.
Looking at it in detail, I think my opinion (only putting in my $.02 worth) stands... for example: the first hunk deals with putting duplicate code in function apachesolr_search_get_params(). To me this is cleanup and not views-related. Also, some parts of the patch are trying to patch old code (by now) or stuff that's active in other issues... (like adding the form to clear the index)
I'm just saying this needs a *little* bit of work so we don't mix issues!
And BTW, great work =) (I need it, so that's why I want it tested and commited) =)
Comment #23
drunken monkey@ "cleanup": Well, you got a point there, but I didn't want to just copy the code from apachesolr_search into my own function, leaving two places to edit if necessary. Of course, I could also do that, but imo it's better this way.
And some new functions in the main module are also needed to communicate with the new module.
@ patching old code: Well, of course, the patch is almost a month old. But I'll try to get it updated over the weekend.
Comment #24
robertDouglass CreditAttribution: robertDouglass commented@drunken monkey: if there are refactorings and cleanups that we could work on separately that'd be a good thing.
I've got a suspicion that the first iteration of this module is going to have to include a patch to views as part of the download.
Comment #25
robertDouglass CreditAttribution: robertDouglass commentedAlso, the views patch isn't linked to from this issue anywhere. If we care about views integration here we need to care for that patch as well.
Comment #26
drunken monkeyThe latest patch, that would already be ready to be committed, can be found at #293841: Allow different back-ends for Views (direct link to the patch).
And yes, at the moment the module does include the Views patch, if we are going to release it this way as 1.0, I should probably also write a short README, explaining how the module can be made to work (applying the patch, or how to obtain the latest version of the patch).
So should I at first delete the refactoring functions and just copy the code, and then post a patch for refactoring?
Comment #27
robertDouglass CreditAttribution: robertDouglass commented"So should I at first delete the refactoring functions and just copy the code, and then post a patch for refactoring?" Yes, please.
Then go ahead and write the README as suggested. We'll commit your SoC work with the patch and have an ongoing lobby effort to get the patch into Views.
Comment #28
drunken monkeyAttached is an updated patch, I hope this time it's OK.
I couldn' test it, though, because atm I've got some problems with my local server.
README coming in the next days...
Comment #29
drunken monkeySorry that it took a little longer, but here is the README.txt. I hope it contains everything necessary.
Comment #30
aufumy CreditAttribution: aufumy commentedThis patch does a few things all in one, contains a module apachesolr_views, modifies apachesolr files, and contains a patch itself (a patch created by a patch).
modifications to files:
* apachesolrlang.module
* apachesolr.module
adds the module:
* apachesolr_views
creates the patch:
* apachesolr_views/views_variable_query_class.patch
=> this patch is similar (but outdated) to the patch in the views issue
Therefore to install this patch involves patching twice:
* apply the merge patch to apachesolr module
* go into contrib/apachesolr_views and apply the newly created views patch
* download the latest views patch from #293841: Allow different back-ends for Views to views module and apply
* enable the apachesolr_views module
Comment #31
aufumy CreditAttribution: aufumy commentedCould the apachesolr_views module be placed in its own drupal project or combined with apachesolr? It would make it easier to submit issues or patches to the module.
I tried out this module and tried using the apachesolr filter or arguments in a view, however it did not return the results I expected.
Thanks
Audrey
Comment #32
langworthy CreditAttribution: langworthy commentedI'm wondering what the status is of this. It's something I could really use and would be happy to help out with if need be.
Comment #33
drunken monkeyWell, at the moment the actual mechanism is (or was, when I last checked) working.
However, the patch that needs to be committed to Views in order for this to work (without manually patching) is still heavily discussed in Views' issue queue: see #293841: Allow different back-ends for Views.
So it can already be used, if you need it, but it looks like it will still take some time until this will be completely integrated.
Comment #34
blackdog CreditAttribution: blackdog commentedSeems like the views patch is near to be commited, #293841: Allow different back-ends for Views, but this patch is really old, so it would need to be re-rolled.
Comment #35
drunken monkeyOK, the changes in both modules were larger than I had expected.
But attached is now a patch that applies to the current apachesolr version and works, afaict. It is based on 15:25, 2,25">this views patch, which is probably be pretty close to what will be committed.
Btw: The new patch doesn't change anything in the module, it just adds the apachesolr_views module to contrib. Some reasonable chances for refactoring to eliminate duplicate code are marked with TODO.
Tests and reviews welcome!
Comment #36
fagocool!
Which is the right patch to use? Your link is broken.
The module is pretty much empty, why not just do that as views integration for the main module?
Comment #37
drunken monkeyOh, sorry, didn't realize that. It's the one in #23 of #293841: Allow different back-ends for Views, from jmiccolis.
And that's something for Robert to decide. I'd have no problem with it, but there is also some gain in being able to switch this off seperately from the main module.
So, yeah, if Robert thinks this is a good idea, it of course would be easy to move this directly to the module.
Comment #38
robertDouglass CreditAttribution: robertDouglass commented+1 for doing it as views integration on the main module. Thank you for tending this patch for so long. I don't expect that we'll actually commit it until the views patch is in, and in a release, so please keep holding out a bit longer =)
Comment #39
pwolanin CreditAttribution: pwolanin commented@robertDouglas - given that this will likely require some specific version of views to work, I think we might want to keep such integration code as a separate module that can do its own checking via hook_requirements.
Comment #40
robertDouglass CreditAttribution: robertDouglass commentedWon't that be taken care of by the views api itself?
That's the only code that would be added to apachesolr.module, and I assume that the patched version of Views would have a version greater than 2.0. If that assumption isn't true, we'd need it in a separate module.
Comment #41
fagoGood question, also see http://drupal.org/node/293841#comment-1281926
Anyway we are elaborating if there is better way to re-create existing views fields without having to reproduce all the code.
Comment #42
drunken monkeyNew patch, including the following improvements:
* Only the required fields are requested from Solr.
* Facets work (if #381076: Base paths in sort/facet blocks is committed too).
* Deactivated taxonomy support until I figure out how to do it. It never worked and this is more honest.
* "Items per page" is respected.
* Multiple sorts work.
* Little addition to README.
Comment #43
drunken monkeyBased on a suggestion from fago, this new patch takes full advantage of existing views field handlers by defining only a single new one, which generically "inherits" from an existing one.
I had my doubts but when I tried it, suddenly everything seemed to work. OK, it did already before I tried this approach, but now we can benefit from all bugfixes/patches/additions to views field handlers and have only one class to alter if things change too much.
Also, it helps you love PHP. ;)
To test, you need to apply the patch in http://drupal.org/node/293841#comment-1294986 to your views module first.
Comment #44
drunken monkeyLittle update:
option_form() is now defined explicitly as simply handing through the call, since pass-by-reference doesn't work with call_user_func_array() (at least not without exploiting a PHP bug).
Also, of course, if this version is preferred over the one with several explicitly inheriting field handlers, I'd rename apachesolr_views_handler_field_generic to apachesolr_views_handler_field before committing. I just named it differently to avoid a) having to save a copy of the original apachesolr_views_handler_field class and b) to distinguish the variants more easily.
Comment #45
drunken monkeySorry, the last patch contained unnecessary classes. Apparently, Eclipse is too stupid to exclude files if you tell it to.
Attached is a patch without these classes. The other works just the same, it only has a few unused files lying in handlers/.
Comment #46
xnickmx CreditAttribution: xnickmx commentedsubscribing
Comment #47
dixon_subscribing
Comment #48
sirkitree CreditAttribution: sirkitree commentedWe can help test this, look for some feedback soon!
Comment #49
m3avrck CreditAttribution: m3avrck commentedsubscribe
Comment #50
drewish CreditAttribution: drewish commentedsubscribing... looks like i'm going to be doing some solr work in the near future.
Comment #51
pwolanin CreditAttribution: pwolanin commentedI think this and any other really substantial sub-projects should probably get their own project that can be maintained independently. I suggested this to Moshe for the Solr-VotingAPI integration, and I think the same for this. Moshe understood well the motivation, since he at one point had hosted many /contrib projects under OG, but eventaully pushed them all out to separate projects.
Comment #52
timcosgrove CreditAttribution: timcosgrove commentedsubscribing
Comment #53
Scott Reynolds CreditAttribution: Scott Reynolds commentedI suggest the following change
Allows you to construct a View without any search terms. ++ ya?
related #358166: Search for just facet(s)
Comment #54
m3avrck CreditAttribution: m3avrck commented#53 I think opens up a ton of great possibilities for creating views with solr backend -- definitely should be part of the main patch!
Comment #55
m3avrck CreditAttribution: m3avrck commentedThere is the bug in the current patch, needs this small fix (too lazy to reroll right now)
Comment #56
Scott Reynolds CreditAttribution: Scott Reynolds commented#53 can be updated as well to actually remove the *. so it looks like this
and it works as well.
Need to study the behavior more to really dig into this.
Comment #57
Scott Reynolds CreditAttribution: Scott Reynolds commentedThis is a re-roll that fixes paging
Of note, it doesn't use pager_query any more (YAY!!!). Thanks to Earl's views code I was able to make the pager_query() stuff go away. Working on a patch for #345606: Unsed global $pager_total to do the same.
This patch fixes
Comment #58
Scott Reynolds CreditAttribution: Scott Reynolds commentedm3avrck pointed out to me that I removed the hook invocation of apachesolr_process_results. This was done on purpose.
Reasons
Comment #59
Scott Reynolds CreditAttribution: Scott Reynolds commentedin order to get filters to work i did a lil magic in the apachesolr_views_query->execute() function
Comment #60
m3avrck CreditAttribution: m3avrck commentedWorking with Scott, here is an updated class that fixes ApacheSolr type to work like the node type selection when using the node backend.
Comment #61
m3avrck CreditAttribution: m3avrck commentedComment #62
Scott Reynolds CreditAttribution: Scott Reynolds commentedphew ok this is a pretty significant update. Items that changed
Of note this patch doesn't make use of Solr_Base_Query. The apachesolr_views_query is analogous to it. As Solr_Base_Query handles the parsing of the urls, application of facets, and returning the query keys etc. So does apachesolr_views_query. They both are wrappers around Drupal_Apache_Solr_Service
Comment #63
Scott Reynolds CreditAttribution: Scott Reynolds commenteddoh! forgot to change the argument handler. And I wanted to add the node_view() style plugin for this..
Comment #64
vssaokar CreditAttribution: vssaokar commentedAfter I applied all the patches mentioned, I dont see a view type of "Apache solr" when I try to create a new view. Any ideas on what might be wrong?
Comment #65
Scott Reynolds CreditAttribution: Scott Reynolds commentedDid you apply the Views patch: http://drupal.org/node/293841#comment-1294986? and clear your Views cache? as plugins are cached.
Comment #66
Scott Reynolds CreditAttribution: Scott Reynolds commentedAfter talking with both RobertDouglass and pwolanin we came to the conclusion that this is probably best implemented seperatally in a module elsewhere. I am in the progress of creating that project and rolling a -dev release.
The big thing we talked about was creating a way for the Views to plug into the facet blocks that work so well. My solution is to create an interface that defines a set of functions. Then all the facet_blocks have to do is to assume that query object implements that interface and away it goes. So this patch contains that as well as the needed changes to the function names in all places within the module.
It also removes the duplicate factory function. apachesolr_drupal_query and apachesolr_current_query are both labeled as factory functions, both really do the same thing except apachesolr_current_query is really used as a static cache. So thats what i did, made it a static cache for all those modules that call it.
I have tested this both with my newer Views implementation and with the standard Apachesolr and it works cleanly. It will also provide a way to properly define "apachesolr_query_class" with an interface by using instanceof operator.
All good things (tm).
Comment #67
Scott Reynolds CreditAttribution: Scott Reynolds commentedThis considerably smaller patch needs a review.
Comment #68
Scott Reynolds CreditAttribution: Scott Reynolds commentedHeres the project
http://drupal.org/project/apachesolr_views
Comment #69
vssaokar CreditAttribution: vssaokar commentedYes, i have applied the views patch and cleared the views cache. still dont see the apache solr as a view type. any other way for me to debug ?
Comment #70
Scott Reynolds CreditAttribution: Scott Reynolds commentedOk i have done my first commit to the module. It provides really interesting stuff, and with this patch on this issue, it will actually work facet blocks provide that the facets you want are configured either has exposed filters or arguments. If they aren't set, clicking the facet link wont work. Its pretty neat, need to check out the CVS HEAD of course as this is still experimental.
Comment #71
Scott Reynolds CreditAttribution: Scott Reynolds commentedupdated patch with against the new Beta
Comment #72
vssaokar CreditAttribution: vssaokar commentedI was able to get the apache solr view module from CVS. And now able to add a view. However I get a error when trying to preview the view. Attached the error in my next comment
Any ideas?
Comment #73
vssaokar CreditAttribution: vssaokar commentedComment #74
Scott Reynolds CreditAttribution: Scott Reynolds commentedThat can happen for a multitude of reasons. Views is telling you "Something went wrong."
If you create a page, give it a path and visit it, you will actually see the error. I get that alot when I forget to start up ApacheSolr
Comment #75
pwolanin CreditAttribution: pwolanin commentedQuick comment:
would be more accurately named
or even
Since we use this for node access and other sorts of added fq params that are unrelated to facets.
Comment #76
pwolanin CreditAttribution: pwolanin commentedI think the change to
apachesolr_drupal_query()
may break the _nodeaccess module - the idea behind the current implementation is that you get a query object that can be manipulated as a subquery without it having the current search parameters filled in.Comment #77
Scott Reynolds CreditAttribution: Scott Reynolds commented@75 I agree. According to http://wiki.apache.org/solr/CommonQueryParameters#head-6522ef80f22d0e50d..., fq stands for filter query
Not sure I understand #76 but I will play with that as its very important to us. There is a very small change to the nodeaccess implementation.
There is no change to apachesolr_drupal_query() there is a change to apachesolr_current_query(). They both, prior to this patch, returned the exact same thing, and took in the exact same parameters (This speaks loudly to this change btw. We are all getting confused on which function really does what and which one is really a factory function). But perhaps removing the static array() cache and replacing it with just a single static cache is the issue you are seeing?
Anyways, i will investigate, marking as need work until i confirm node_access works. And i probably need add in some more hand holding so its easier for people to get this up and running.
Comment #78
Scott Reynolds CreditAttribution: Scott Reynolds commentedok this is an updated patch taking both in notes about 75 and 76. node_access was indeed broken. This patch fixes it up.
This does touch a lot of code but mostly in minor ways, function name changing. With the expection of de-coupling apachesolr_drupal_query() and apachesolr_current_query(). My current Views implementation works with this patch
Comment #79
Scott Reynolds CreditAttribution: Scott Reynolds commentedplz review
Comment #80
Scott Reynolds CreditAttribution: Scott Reynolds commentedMissed the new date block. Heres the fix
Comment #81
pwolanin CreditAttribution: pwolanin commentedpatch looks basically fine - possibly needs a little cleanup in the doxygen for the interface (facet -> filter).
Obviously this will restrict a little our ability to refactor the query class if it must must conform to the interface - for instance, the handling of sorts is a bit ugly now compared to other parts of the code.
Comment #82
Scott Reynolds CreditAttribution: Scott Reynolds commentedI agree sorts are messy. You can through the Views interface set up sorts and maybe that becomes the basis for the new sort setup in the query class? The way Solr_Base_Query works is by string, maybe basing it off what drunkenmonkey did for the Views interface is a cleaner way to go? Its fairly straight forward just adds adds the sort to its internal $params array.
Comment #83
pwolanin CreditAttribution: pwolanin commentedwe should probably refactor the query class to hold the arrray of params? we would need get/set/add_param() kind of methods - and I guess filters would be a special case in terms of having a separate set of methods since we are manipulating those so widely?
Comment #84
Scott Reynolds CreditAttribution: Scott Reynolds commentedNot sure refactoring it that way would add anything. I think something as simple as maintaining a $sort_string property would do you just fine. That solves this problem.
In the apachesolr Views project I maintain a params array because there are three discrete stages (build, alter, execute). This allows me to semantically line up with how Views builds its queries. The standard search probably doesn't need it.
Of course with all this being said, I'm not sure how to get the facet sort blocks working with my implementation. It might have to be an alter hook that catches something in the url and changes the query (probably the same variable that the standard search uses). Probably end up being a lil hackish i think, but will make it work i hope. That is the one remaining thing.
Comment #85
vssaokar CreditAttribution: vssaokar commentedI get this error when trying to access the view,
Fatal error: Call to undefined method views_query::add_filter() in /home/9a0440c5/web/public/modules/apachesolr_views/handlers/apachesolr_views_handler_filter_type.inc on line 50
http://desitrack.com/test/Business
I am using the latest code from apachesolr_views module. Also have applied the views patched as mentioned. What am I missing? thanks in advance.
Comment #86
pwolanin CreditAttribution: pwolanin commenteddww reminded me today that we do want a better API for handling sort fields so that we can, at least, use field aliases. Also, solr does support sorting on multiple fields.
So, I may commit this, but likely we will want to alter the interface soon.
Comment #87
pwolanin CreditAttribution: pwolanin commentedcommitted attached to 6.x (some code comment changes). needs follow-up for sort re-working, etc.
Comment #88
mkalkbrennerAs already mentioned in #76 this patch breaks sub queries added via hook apachesolr_modify_query.
Before that patch a modification to the query object was not stored using apachesolr_current_query but applied directly before searching via solr.
Now the modification is stored which causes every link in facets to contain the sub query. For example a facet link for term id 27 looks like this (simplified):
Now two bad things happen if you click such a link:
1. Hypothetically speaking, the sub query gets duplicated because the filters parameter will be parsed when creating the query object on the result page and become part of the main query. The original sub query will also be added via the hook.
2. You end up with an error message because parsing filters messes up the original sub query. The property fields of the query object looks like this after parse_filters():
Type "page" is gone and "story" became "story)". This ends up in a solr request containing
fq=type:story)
which causes a ParseException.Comment #89
Scott Reynolds CreditAttribution: Scott Reynolds commentedDoes this work?
I do have mixed feelings about sub_queries. And perhaps this is really what subqueries are for (being totally separate from the actual query), and that has value.
perhaps in the _clone() method, we remove any subqueries?
Comment #90
Scott Reynolds CreditAttribution: Scott Reynolds commentedOk here ya go. I realized my error. I moved this call: apachesolr_current_query($query); to far down through the process. This lil patch should fix it. Plz test it
Comment #91
pwolanin CreditAttribution: pwolanin commentedLooks like a reasonable fix.
Comment #92
mkalkbrenner@ #90
I had the same idea. Unfortunately it didn't solve the issue.
You removed cloning from apachesolr_current_query(). So it doesn't matter if you store the query before or after apachesolr_modify_query hook. You always modify the same query object passed via reference.
Here's a small patch that gets sub queries to work again in my setup. But it reintroduces cloning so I don't know which side effects this might have.
Comment #93
pwolanin CreditAttribution: pwolanin commentedIn fact, it should probably clone it both on the set and the return
Comment #94
Scott Reynolds CreditAttribution: Scott Reynolds commentedyep pwolanin is right, needs to clone on both set and return.
I got lazy...
Comment #95
pwolanin CreditAttribution: pwolanin commentedHere's a combined patch - please test so we can get this fixed asap.
Comment #96
pwolanin CreditAttribution: pwolanin commentedComment #97
pwolanin CreditAttribution: pwolanin commentedhelps if the variables have the right name.
Comment #98
pwolanin CreditAttribution: pwolanin commentedthis is working for me well enough, so I committed it, but please confirm and marked fixed.
Comment #99
mkalkbrennerWorks here as well.
Comment #101
FrancewhoaNice feature thanks all. Much easier to theme Apache Solr search result page with Views theming. Subscribing.
Personal note: Latest updates are posted on Apache Solr Views module project page at http://drupal.org/project/apachesolr_views