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

damien tournoud’s picture

I'm sorry, but what?

$ php -r "echo gmdate('r', 1243951119);"
Tue, 02 Jun 2009 13:58:39 +0000

That looks perfectly ok to me.

robertdouglass’s picture

The comparison in the WHERE query looks wrong. Sorry I wasn't specific:
asn.changed = 1243951119 AND asn.nid > 14307
How likely is it that asn.changed will equal $some_exact_date ?

damien tournoud’s picture

This is done to discriminate nodes that changed in the same second. That explains the ORDER BY changed, nid.

robertdouglass’s picture

Oh, interesting. Is this something that could go away when we get a locking API?

damien tournoud’s picture

Not 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.

robertdouglass’s picture

Status: Active » Closed (won't fix)

I think I get it. Thanks.