===== Présentation =====

 Solar est un moteur d'indexation, et un moteur de recherche textuelle, qui expose ses services REST sous la forme de serveur web.
 
 On peut donc l'invoquer directement via des requêtes web, pour créer de nouveaux enregistrements ou requêter les données qu'il contient.
 
 Il met également à disposition un portail web qui fournit une IHM permettant de le consulter.
 
 Solar repose et se sert en fait de lucene, qui est le moteur d'indexation.
 Lucene stocke ses données sur un disque dur et ne peut être accédé que depuis le poste qui héberge ses données.
 
 Solar étend, ouvre donc le potentiel de Lucene en permettant à n'importe qui de communiquer avec lui.
 
 Un serveur solar peut héberger plusieurs index.
 
 
===== Principes généraux de fonctionnement d'un index SOLAR =====

 L'unité de base d'un index SOLAR est le __document__.
 A l'image d'un struct en C, il s'agit d'un moule qui décrit un ensemble de champs monovalué ou multivalués.

 A savoir : une requête sur un index renvoie soit tout le document
 
 Il faut donc avant toute chose définir/décrire l'index. Pour chaque index, on doit écrire 2 fichiers : 
  * solrconfig.xml
 
 
  * schema.xml, le plus important, celui qui décrit l'index ; en voici un exemple
 
<sxh xml>
	<?xml version="1.0" encoding="UTF-8" ?>
	<!-- Version OCTAV : ${project.version} -->
	<schema name="oeuvre" version="1.4">

		<fields>
			<field name="id" type="string_lowercase" indexed="true" stored="true"/>
			<field name="_version_" type="long" indexed="true" stored="true"/>
			...
			<field name="nomfidparticipant" type="string_lowercase" indexed="false" stored="true" multiValued="true"/>
			...
			<dynamicField name="cms_typeEntree_*" type="string_lowercase"    indexed="true"  stored="true"/>
			<field name="nombreDeReferences" type="long" indexed="true" stored="true"/>
		</fields>
		<uniqueKey>id</uniqueKey>
			
		<types>
			<fieldType name="string_lowercase" class="solr.TextField" positionIncrementGap="100" omitNorms="true" >
				<analyzer type="index">
					<tokenizer class="solr.KeywordTokenizerFactory" />
					<charFilter class="solr.MappingCharFilterFactory" mapping="mapping-FoldToASCII.txt"/>
					<filter class="solr.LowerCaseFilterFactory" />
					<charFilter class="solr.PatternReplaceCharFilterFactory" pattern="\\s+" replacement=" "/>
					<filter class="solr.TrimFilterFactory"/>
				</analyzer>
				<analyzer type="query">
					<tokenizer class="solr.KeywordTokenizerFactory" />
					<charFilter class="solr.MappingCharFilterFactory" mapping="mapping-FoldToASCII.txt"/>
					<filter class="solr.LowerCaseFilterFactory" />
					<charFilter class="solr.PatternReplaceCharFilterFactory" pattern="\\s+" replacement=" "/>
					<filter class="solr.TrimFilterFactory"/>
				</analyzer>
			</fieldType>			
			<fieldType name="long" class="solr.LongField" />
			<fieldType name="date" class="solr.TrieDateField" />
			...
		</types>
	</schema>
</sxh>
 
 On retrouve donc au moins 3 éléments dans la description : 
  * <fields> 	: définitions des champs
  * <uniqueKey>	: clé unique de l'index
  * <types>		: définitions des types, associés au champs.
 
 Remarque sur <uniqueKey> : Ca sert à garantir l'unicité (la non duplication) d'un document clairement identifié dans l'index ; dans le cas où l'on tente d'enregistrer un document avec cet clé,
 alors le précédent document sera écrasé de l'index et le nouveau document vient le remplacer.
 
==== Définition d'un champ ====
 Pour chaque champ déclaré avec <field>, on doit décrire  : 
  * son nom (il servira dans les requêtes)
  * son type : qui sera décrit après
  * stored : si il doit être restitué lors des requêtes
  * indexed : si il doit être indexé pour la recherche
  * multiValued : si il peut contenir plusieurs valeurs (si omis, à false)

 Il faut bien comprendre que pour tous les champs définis avec indexed="true", alors SOLAR (Lucene) devra mettre en place un ou plusieurs index dessus (un peu comme une base de données).

  
==== Définition d'un type ==== 
 
 __Remarque préliminaire importante : quand un document est indexé, la (ou les) valeur(s) de ses champs (si multivalued) sera indexée(s) sans aucune modification.__
 
 Un type ne correspond pas du tout à l'idée qu'on s'en fait au début. 
  
 Type est orienté à définir le type biensur, mais surtout la recherche à partir d'un champ : il définit en général 2 analyzers : 
   - __query__ : 1 pour transformer les valeurs de recherches dans la requête recue
   - __index__ : 1 pour transformer les valeurs des champ indexé dans l'index
 
 Les analyzer sont en fait constitué d'une séquence ordonnées de transformers de valeur ; il peuvent contenir le type d'opération suivantes :
  * Transformation en uppercase/Lowercase
  * Remplacement string avec des regex
  * Tokenizer : transformation d'un String en liste de String (en fournissant un séparateur)
  * Suppression d'espace en début ou fin de chaine
  
 Du coup, lors d'une requête sur un index SOLAR, imaginons sur les champs c1 et c2 : 
 
 E1 : SOLAR va transformer la valeur c1 de la requête en exécutant les transformers de l'analyzer 'query' du type de c1. Idem pour c2.
 
 E2 : SOLAR va transformer la valeur c1 du document en exécutant les transformers de l'analyzer 'index' du type de c1.
 En vrai, il a sans doute déjà fait ce travail à l'indexation du document (c'est juste pour expliquer qu'on compare des valeurs transformées)
 
 E3 : il va essayer du coup de rechercher dans sa base des documents dont les valeurs transformées indexées des champs c1 et c2 correspondent aux valeurs transformées c1 et c2 de la requête.
 

 __Ce qu'il y a de fondamental à comprendre alors, c'est que les résultats de recherche ne sont pas de simples filtres, mais correspondent plus à scoring de match, 
 i.e des calculs de correspondances entre les valeurs recherchées transformées et celles transformées de l'index.__
 
 Malgré ce que je viens de dire, il existe néanmoins la possibilité d'ajouter dans la requête des filtres pur et dur.
 

===== Présentation d'une requête SOLAR =====

Voici tous les éléments que l'on peut retrouver dans une requête SOLAR

 Avant de commencer à illustrer, à savoir : 
 
   ou logique : +A+B, ou +A B  signifie A ou B

==== Scoring ====
	{!boost b=ln(sum(nombreDeReferences,2))}
	+((+titre:mer titre:"mer"~30^2 titreKeyword:"mer"^2)(+sousTitre:mer sousTitre:"mer"~30 sousTitreKeyword:"mer")(+codeGeneral:mer codeGeneral:"mer"~30)(+numeroCatalogueProducteur:mer numeroCatalogueProducteur:"mer"~30))
	+((+nomparticipantidx:rene nomparticipantidx:"rene"~30 nomparticipantidx_keyword:"rene"))

 Explications : 
  * nombreDeReferences = nombre d'autres oeuvres qui référence cette oeuvre, 
  * ln = Logarithme népérien
  * "mer"~25^2   signifie : Si la distance lexicale du titre du document par rapport à "mer" est de moins de 25, alors on applique un coefficient de 2 au scoring

==== Facettes ====
 Les facettes correspond à des countBy() sur les éléments retounés, mais sans la pagination (voir plus pas)
	&facet.field=origine&facet.field=genreregroupe&facet=true&facet.mincount=1&facet.sort=index
	&facet.query=referencementOeuvre:"000000000000"&facet.query=-referencementOeuvre:"000000000000"&facet.query=-npu:0

==== Filter query ====
	&fq=+(typeOeuvre:oeuvresimple typeOeuvre:film typeOeuvre:caisseglobale typeOeuvre:serie typeOeuvre:episode typeOeuvre:clip typeOeuvre:publicite typeOeuvre:marque typeOeuvre:produitpub typeOeuvre:coffret typeOeuvre:disque typeOeuvre:programmetype typeOeuvre:produit)

==== Trie et pagination ====
	&sort=titreTri asc&start=0&rows=35

===== Installation d'un serveur SOLAR =====
 A savoir que SOLAR embarque Lucene, donc il faut juste installer SOLAR

 Il faut installer le serveur solar en local. Pour ca il y a un dossier OCTAV-TOOLS sur R:
		On installe ça dans 
	D:\dev\serveurs\solr-4.7.2\
 On configure 
	6 types d'index
	Pour chaque type, dossier data (données indexée) et conf (conf de création des index, dont notamment schema.xml)
 On lance le serveur
	Editer le fichier suivant pour mettre le port à 8983 puis le lancer.
	D:\dev\serveurs\solr-4.7.2\example\start.bat 


  <SolarInstall>\solr\<NomIndex>\conf