Archive for January 2013
Solr – Filtrare risultati irrilevanti
la ricerca di frasi composte da molte parole pone diversi problemi.
Il minimo numero di parole che devono essere trovate non può essere il 100% perchè non tutte le parole hanno la stessa importanza e la presenza di quelle chiave è sufficiente a trovare documenti attinenti.
però il numero di risultati trovati viene comunque influenzato malamente dalle parole poco significative.
per esempio se cercassi “il cane e la gatta” con un numero minimo di parole =3 (mm=3) avrei come ultimi risultati a bassa rilevanza conententi solo “il” e “e” “la”. Chiaramente si può intervenire eliminando gli articoli italiani dall’indice, ma questo è solo un esempio il problema si riproporrebbe con altre parole diffuse, ad esempio cercando il titolo di un film.
Ieri ho aggiunto un nuovo trucchetto al mio arsenale solr
q={!frange l=0.75}query($qq)&qq={!dismax mm=1 qf=”name description” pf=”name description” qt=myconf}tanto va la gatta al lardo che ci lascia lo zampino
Questo mostriciattolo esegue una query dismax su alcuni campi, richiamando le impostazioni di un query type e modificandolo in modo da trovare tutti i risultati che matchano almeno una parola. Fatto questo i risultati vengono filtrati in modo da avere almeno uno score 0.75
Volendo generalizzare, se analizzando la rilevanza dei risultati prodotti doveste scoprire che sotto un certo valore quello che esce è generalmente irrilevante e non vale la pena listarlo potete intervenire aggiungendo un frange e magia non dovete ritarare tutta la configurazione del qt come il mm, i pesi di qf e pf ecc.
enjoy
@RequestParam intercettare gli errori e modificare la risposta
con spring è comodissimo ricevere i parametri delle richieste utilizzando l’annotazione @RequestParam
per esempio
@RequestMapping(“/getCorrelatiProdotti.do”)
public @ResponseBody Object getRelatedProductsHttpGet (
@RequestParam(value = “skuItem”, required = true) String sku,
@RequestParam(value = “idSito”, defaultValue = “0”) String idSito,
@RequestParam(defaultValue=”true”) boolean jsonp,
ModelMap model)
definisce diversi parametri tra cui uno obbligatorio, e uno booleano. Se il parametro obbligatorio manca o il booleano riceve un testo che booleano non può essere (vale anche per numeri ecc) normalmente viene inviata una risposta in stato http 400.
Avendo la necessità di rispondere un JSON anche in caso di errore ho dovuto modificare questo comportamento. Dopo un sacco di ricerche ho trovato il modo per farlo
@ExceptionHandler(MissingServletRequestParameterException.class)
public @ResponseBody Object handleMyException(Exception exception, HttpServletRequest request,
HttpServletResponse response) {
response.setStatus(HttpServletResponse.SC_BAD_REQUEST);
/** omissis prepara degli oggetti con la descrizione degli errori */
Map<String,Object> ret = new HashMap<String, Object>();
ret.put(“State”, state);
ret.put(“error”, error);
return ret;
}
L’annotazione @ExceptionHandler permette di intercettare l’eccezione, i parametri del metodo possono essere i più disparati, tra cui l’eccezione, la request e la response.
a questo punto non bisogna fare altro che restituire un oggetto con la struttura che si vuole inviare al client.