Pourquoi ce genre de travail dans Solr?

Question

J'ai besoin de trier sur un type de champ date, dont le nom est "mod_date".

Il fonctionne comme ça dans l'adresse barre du navigateur:

http://localhost:8983/solr/select/?&q=bmw&sort=mod_date+desc 

Mais je me sers d'un client phpSolr qui envoie une URL à Solr, et l'URL envoyé est ceci:

fq=+category%3A%22Bilar%22+%2B+car_action%3AS%C3%A4ljes&version=1.2&wt=json&json.nl=map&q=%2A%3A%2A&start=0&rows=5&sort=mod_date+desc 

// This wont work and is echoed after this in php: 

$queryString = http_build_query($params, null, $this->_queryStringDelimiter); 
$queryString = preg_replace('/%5B(?:[0-9]|[1-9][0-9]+)%5D=/', '=', $queryString); 

Cela ne marchera pas, je ne sais pas pourquoi!

Tout le reste fonctionne bien, tous les bons champs sont retournés. Mais le genre ne fonctionne pas.

Des idées?

Merci

BTW: Le champ "mod_date" contient quelque chose comme:

2010-03-04T19:37:22.5Z 

EDIT:

D'abord j'utiliser PHP pour envoyer à un SolrPhpClient qui est un autre fichier php-disant service.php:

require_once('../SolrPhpClient/Apache/Solr/Service.php'); 
    $solr = new Apache_Solr_Service('localhost', 8983, '/solr/'); 
    $results = $solr->search($querystring, $p, $limit, $solr_params); 

$ solr_params est un tableau qui contient le solr -paramètres (q, fq, etc).

Maintenant, en service.php:

  $params['version'] = self::SOLR_VERSION; 

    // common parameters in this interface 
    $params['wt'] = self::SOLR_WRITER; 
    $params['json.nl'] = $this->_namedListTreatment; 

    $params['q'] = $query; 
    $params['sort'] = 'mod_date desc'; // HERE IS THE SORT I HAVE PROBLEM WITH 

    $params['start'] = $offset; 
    $params['rows'] = $limit; 
      $queryString = http_build_query($params, null, $this->_queryStringDelimiter); 
      $queryString = preg_replace('/%5B(?:[0-9]|[1-9][0-9]+)%5D=/', '=', $queryString); 

    if ($method == self::METHOD_GET) 
    { 
return $this->_sendRawGet($this->_searchUrl . $this->_queryDelimiter . $queryString); 
    } 
else if ($method == self::METHOD_POST) 
    { 
    return $this->_sendRawPost($this->_searchUrl, $queryString, FALSE, 'application/x-www-form-urlencoded'); 
    } 

Les $results contiennent les résultats de Solr ... C'est donc la façon dont je dois aller au travail (via php).

Ce code ci-dessous (également en haut de ce Q) fonctionne mais c'est parce que je le colle dans la barre d'adresse manuellement, pas via PHPclient. Mais c'est juste pour le débogage, je dois le faire fonctionner via le PHPclient:

http://localhost:8983/solr/select/?&q=bmw&sort=mod_date+des // Not via phpclient, but works 

MISE À JOUR (2010-03-08): J'ai essayé codes Donovans (les urls) et ils fonctionnent très bien. Maintenant, j'ai remarqué que c'est l'un des paramètres qui fait que le 'SORT' ne fonctionne pas. Ce paramètre est le paramètre "wt". Si nous prenons l'URL du haut de ce Q, (fq=+category%3A%22Bilar%22+%2B+car_action%3AS%C3%A4ljes&version=1.2&wt=json&json.nl=map&q=%2A%3A%2A&start=0&rows=5&sort=mod_date+desc), et simplement supprimer le paramètre "wt", alors le tri fonctionne. MAIS les résultats apparaissent différemment, ce qui rend mon code php incapable de reconnaître les résultats que je crois. Donovan saurait cela je pense. Je devine que pour que le PHPClient fonctionne, les résultats doivent être dans une structure spécifique, qui est désordonnée dès que j'enlève le paramètre wt.

Donovan, aidez-moi s'il vous plaît ...

Voici quelques informations que j'utiliser votre SolrPhpClient pour: J'ai un site de petites annonces, qui utilise MySql. Mais pour la recherche, j'utilise Solr pour rechercher des champs indexés. Alors Solr retourne un tableau de ID: nombres (pour toutes les correspondances des critères de recherche). Ensuite, j'utilise ces ID: numéros pour trouver tout dans une base de données MySql et récupérer toutes les autres informations (par exemple, l'information n'est pas consultable).Donc, simplifié: Recherche -> Solr renvoie toutes les correspondances dans un tableau d'ID: nrs -> Id: les numéros de Solr sont les mêmes que les numéros d'identification dans la base de données MySql, donc je peux juste faire une simple correspondance enregistrer avec l'ID correspondant à l'ID du tableau de résultats Solr.

Je n'utilise pas de facettage, pas de renforcement, pas de pertinence ou d'autres choses de fantaisie. Je trier seulement par le dernier mis classifié, et donne l'option aux utilisateurs de trier également sur le prix le meilleur marché. Rien de plus.

Puis j'utilise le paramètre "fq" pour faire des requêtes sur différents champs dans Solr en fonction de la catégorie choisie par les utilisateurs (exemple "cars" dans ce cas qui dans ma langue est "Bilar").

Je suis vraiment coincé avec ce problème ici ... Merci pour toute l'aide

Answer 1

Comme indiqué dans les commentaires de débordement de la pile, votre requête de navigateur est différent de votre requête basée client php - pour supprimer ce de la équation que vous devriez tester avec ce corrigé. Pour obtenir les mêmes résultats que l'aurait dû examiner la requête en fonction du navigateur que vous êtes le code php quelque chose comme ceci:

$solr = new Apache_Solr_Client(...); 

$searchOptions = array(
    'sort' => 'mod_date desc' 
); 

$results = $solr->search("bmw", 0, 10, $searchOptions); 

Au lieu de cela, je pense qu'il ressemble plus:

$searchOptions = array(
    'fq' => 'category:"Bilar" + car_action:Sälje', 
    'sort' => 'mod_date desc' 
) 

$solr->search("\*:*", 0, 10, $searchOptions); 

Ce que je vous attends voir est que les résultats du client php seront les mêmes que les résultats basés sur le navigateur, et j'imagine que la même chose se produirait si vous l'avez fait à l'opposé - prenez vos paramètres actuels du client php et les appliquer correctement à la requête basée sur le navigateur.

Maintenant sur votre problème, vous ne voyez pas les documents triés correctement.

Je voudrais essayer cette requête, ce qui est l'équivalent du code client basé php:

http://localhost:8983/solr/select/?&q=%2A%3A%2A&fq=+category%3A%22Bilar%22+%2B+car_action%3AS%C3%A4ljes&sort=mod_date+desc 

par rapport à cette requête, qui déplace la requête de filtre dans la requête principale:

http://localhost:8983/solr/select/?&q=+category%3A%22Bilar%22+%2B+car_action%3AS%C3%A4ljes&sort=mod_date+desc 

et voir s'il y a une différence. Si tel est le cas, cela pourrait être un bug dans la façon dont les résultats des requêtes filtrées en cache sont utilisés et triés par solr - ce qui ne serait pas un problème avec le client, mais le service solr lui-même.

Espérons que cela vous rapproche d'une anser.

Answer 2

Utilisez les valeurs de session pour enregistrer les paramètres de tri.

Answer 3

La réponse rapide au cas où quelqu'un tente de trier par solr-php-client:

$searchOptions = array('sort' => 'field_date desc'); 

Ditch le signe + que vous habituellement mis sur l'URL. Il m'a fallu un certain temps pour comprendre, je l'encodais et le mettais partout ...

Answer 4

C'est peut-être lié au paramètre json.nl=map. Lorsque la réponse est définie sur JSON avec wt=json et json.nl=map, les facettes sont et non triées comme prévu avec les options facet.sort ou f.<field_name>.facet.sort=count|index.

par exemple.avec facet.sort=count et wt=json seulement, je reçois:

"dc_coverage": [ 
    "United States", 
    5, 
    "19th century", 
    1, 
    "20th century", 
    1, 
    "Detroit (Mich.)", 
    1, 
    "Pennsylvania", 
    1, 
    "United States--Michigan--Detroit", 
    1, 
    "United States--Washington, D.C.", 
    1 
] 

Mais avec facet.sort=count, wt=json, etjson.nl=map en option, vous pouvez voir le tri est perdu:

"dc_coverage": { 
    "19th century": 1, 
    "20th century": 1, 
    "Detroit (Mich.)": 1, 
    "Pennsylvania": 1, 
    "United States": 5, 
    "United States--Michigan--Detroit": 1, 
    "United States--Washington, D.C.": 1 
} 

Il y a plus d'informations ici A propos du formatage de la réponse JSON lors de l'utilisation json.nl=map: https://cwiki.apache.org/confluence/display/solr/Response+Writers#ResponseWriters-JSONResponseWriter