Closed (won't fix)
Project:
Apache Solr Search
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
21 Jul 2009 at 08:57 UTC
Updated:
21 Jul 2009 at 09:55 UTC
This query doesn't make sense to me: SELECT COUNT(asn.nid) FROM apachesolr_search_node asn WHERE (asn.changed > 1243951119 OR (asn.changed = 1243951119 AND asn.nid > 14307)) AND asn.status = 1
asn.changed = 12345... can't be right.
The query with this logic happens twice:
/**
* Helper function for modules implmenting hook_search's 'status' op.
*/
function apachesolr_index_status($namespace) {
list($excluded_types, $args, $join_sql, $exclude_sql) = _apachesolr_exclude_types($namespace);
$total = db_result(db_query("SELECT COUNT(asn.nid) FROM {apachesolr_search_node} asn ". $join_sql ."WHERE asn.status = 1 " . $exclude_sql, $excluded_types));
$remaining = db_result(db_query("SELECT COUNT(asn.nid) FROM {apachesolr_search_node} asn ". $join_sql ."WHERE (asn.changed > %d OR (asn.changed = %d AND asn.nid > %d)) AND asn.status = 1 " . $exclude_sql, $args));
return array('remaining' => $remaining, 'total' => $total);
}
/**
* Returns an array of rows from a query based on an indexing namespace.
*/
function apachesolr_get_nodes_to_index($namespace, $limit) {
$rows = array();
if (variable_get('apachesolr_read_only', 0)) {
return $rows;
}
list($excluded_types, $args, $join_sql, $exclude_sql) = _apachesolr_exclude_types($namespace);
$result = db_query_range("SELECT asn.nid, asn.changed FROM {apachesolr_search_node} asn ". $join_sql ."WHERE (asn.changed > %d OR (asn.changed = %d AND asn.nid > %d)) AND asn.status = 1 ". $exclude_sql ."ORDER BY asn.changed ASC, asn.nid ASC", $args, 0, $limit);
while($row = db_fetch_object($result)) {
$rows[] = $row;
}
return $rows;
}
Comments
Comment #1
damien tournoud commentedI'm sorry, but what?
That looks perfectly ok to me.
Comment #2
robertdouglass commentedThe comparison in the WHERE query looks wrong. Sorry I wasn't specific:
asn.changed = 1243951119 AND asn.nid > 14307How likely is it that asn.changed will equal $some_exact_date ?
Comment #3
damien tournoud commentedThis is done to discriminate nodes that changed in the same second. That explains the ORDER BY changed, nid.
Comment #4
robertdouglass commentedOh, interesting. Is this something that could go away when we get a locking API?
Comment #5
damien tournoud commentedNot really. The module indexes nodes in batch, ordered by (changed, nid). The batch can end anywhere, so it is possible that there are still nodes with the same changed date but a higher nid.
Comment #6
robertdouglass commentedI think I get it. Thanks.