Closed (won't fix)
Project:
Apache Solr Search
Version:
6.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
31 Aug 2008 at 19:58 UTC
Updated:
9 Dec 2008 at 14:56 UTC
Jump to comment: Most recent file
Comments
Comment #1
JacobSingh commentedComment #2
robertdouglass commentedYup. This is a confirmed issue for Drupal, too. Need to check and see if they resolved it in core, and if so, how.
Comment #3
robertdouglass commentedComment #4
robertdouglass commentedTODO before commit: track this issue down in core and see if it has been committed and what the solution is. Look here for clues: http://groups.drupal.org/node/10569
Comment #5
JacobSingh commentedComment #6
JacobSingh commentedOkay, this bug has been fixed through a re-factoring in Drupal-6...
However, it seems it is still there in Drupal-5.
Here is an apt description;
http://drupal.org/node/42277#comment-846833
There is a patch attached to that node. I suggest we rip that query from there and test and apply.
For the D6 branch, I'm thinking we might want to look into refactoring it to use the new method used in node.module... Although I haven't a clue how it works. I can commit to fixing the D5 branch, can someone else more knowledge about D6 tackle the other one?
If you're curious about the difference, here it is:
node.module in D5:
In particular see the last bit:
node.module in D6:
Comment #7
robertdouglass commentedYeah, there is basically a "reindex" flag in the search_dataset table that lets us mark a node as needing re-indexing. It works much better, but begs the question, are we dependent on using the core search index? A lot of people are attracted to ApacheSolr so that they can stop using the core search index.
Please move ahead with the fix to D5, and forward port it to D6 (if it works) until we come up with a better strategy for D6.
Comment #8
john.money commentedMissed this issue and posted a dupe because I filter by 5.x.
Here's my patch from #309878 for 5.x-dev (0917). Of particular note, there is no need to recalculate last_change when ordering.
edit: patch has been tested against a database of 50k+ nodes and there is 100% indexing coverage.
Comment #9
JacobSingh commentedWorks for me. I tested against 6.x too and it works.
Can I get a witness? If it is good, I'll commit it.
Comment #10
robertdouglass commentedgo for it.
Comment #11
robertdouglass commentedI'm committed this. BUT:
Can anyone answer me the question - is IF() cross database compatible? Or are we now officially only MySQL compatible?
Comment #12
john.money commentedGiven that the original code came out of node.module (with the IF), I would assume that it is a compatible function. Otherwise, parts of core are also only MySQL compatible.
Comment #13
john.money commentedbump...
We've got Solr humming along on ConsumerSearch. Now I have some time (a little at least) to work on more patches we have on our implementation.
Comment #14
pwolanin commentedNote that the tracking mechanism has been totaly rewritten already and now lives in a separate table. Might be bug or improvements to be made, but the ugly query is reall no longer an issue for 6.x
Comment #15
JacobSingh commented