laravel scout database
v2.4.0
Ce package fournit un pilote générique Laravel Scout qui effectue une recherche en texte intégral sur les données du modèle indexées à l'aide d'une base de données SQL comme backend de stockage. Les données indexées sont stockées sous une forme normalisée, permettant une recherche efficace et floue qui ne nécessite pas de correspondance complète et / ou exacte.
Ce pilote est une alternative à teamtnt/laravel-scout-tntsearch-driver . La principale différence est que ce pilote fournit moins de fonctionnalités (comme la recherche GEO). Au lieu de cela, il fonctionne avec tous les systèmes de base de données pris en charge par Laravel lui-même (qui sont essentiellement tous les pilotes APD). De plus, l'algorithme de recherche est légèrement différent.
Tous les tests sont effectués via des actions GitHub pour PHP 8.0, 8.1 et 8.2 sur les systèmes de base de données suivants:
Les limitations réelles concernant les systèmes de base de données prises en charge sont principalement liées à l'utilisation de l'expression de la table commune à l'aide de Staudenmeir / Laravel-CTE. Veuillez vous assurer que votre système de base de données est pris en charge avant d'utiliser le package, ou vous pouvez exécuter des erreurs de base de données.
Vous pouvez installer le package via le compositeur:
composer require namoshek/laravel-scout-databaseAprès avoir installé le package, le fichier de configuration ainsi que les migrations doivent être publiés:
php artisan vendor:publish --provider= " NamoshekScoutDatabaseScoutDatabaseServiceProvider " --tag= " config "
php artisan vendor:publish --provider= " NamoshekScoutDatabaseScoutDatabaseServiceProvider " --tag= " migrations " Si vous souhaitez utiliser un préfixe de table différent de scout_ pour les tables créées par ce package, vous devez modifier la configuration ainsi que les migrations copiées en conséquence. Lorsque vous l'avez fait, vous pouvez ensuite appliquer les migrations de la base de données:
php artisan migratev0.x à v1.x Avec la nouvelle version, le schéma de base de données a changé et les nouvelles migrations doivent être publiées en utilisant:
php artisan vendor:publish --provider= " NamoshekScoutDatabaseScoutDatabaseServiceProvider " --tag= " migrations "Le même indice que celle mentionnée ci-dessus dans la section d'installation s'applique également aux migrations nouvellement publiées.
La configuration a été légèrement réduite et vous pouvez comparer le nouveau fichier de configuration avec l'ancien pour supprimer les paramètres obsolètes. Sauter cette pièce n'a cependant aucun impact négatif sur les performances du conducteur scout.
La NamoshekScoutDatabaseCommandsCleanWordsTable::class a été supprimée et vous devriez la décoller, si vous l'avez ajoutée précédemment.
La plupart des occurrences de champs et de méthodes protected ont été transformés en private pour simplifier le développement en ce qui concerne les changements de rupture en arrière à l'avenir. Si vous n'avez pas subi activement de parties de l'implémentation, cela ne vous affecte pas du tout.
Afin de demander à Scout d'utiliser le pilote fourni par ce package, vous devez modifier l'option driver dans config/scout.php en database . Si vous n'avez pas modifié le fichier de configuration SCOUT, vous pouvez également définir la variable d'environnement SCOUT_DRIVER en database .
Toutes les options de configuration disponibles du package lui-même peuvent être trouvées dans config/scout-database.php . Les options sont décrites en profondeur dans le fichier lui-même. Par défaut, le package utilise le UnicodeTokenizer et le PorterStemmer qui convient à la langue anglaise. La recherche ajoute un joker traînant au dernier jeton et tous les termes de recherche ne doivent pas être trouvés pour qu'un document apparaisse dans les résultats (il doit y avoir au moins une correspondance cependant).
Vous pouvez également ajouter un wildcard à chaque jeton de recherche en permettant wildcard_all_tokens dans le fichier de configuration, ce n'est pas recommandé pour des raisons de performance.
Une installation de base ne vous oblige probablement pas à modifier l'un de ces paramètres. Juste pour vous assurer, vous devriez cependant consulter l'option connection . Si vous souhaitez changer cela, faites-le avant d'exécuter les migrations ou les tables seront créées en utilisant la mauvaise connexion de la base de données.
Actuellement, seul un UnicodeTokenizer est disponible. Il divisera les chaînes à n'importe quel caractère qui n'est ni une lettre, ni un nombre selon les motifs p{L} et p{N} regex. Cela signifie que les points, les colons, les tirets, les espaces blancs, etc. sont des critères divisés.
Si vous avez des exigences différentes pour un tokenizer, vous pouvez fournir votre propre implémentation via la configuration. Assurez-vous simplement qu'il implémente l'interface Tokenizer .
Actuellement, tous les tiges implémentées par le package wamania/php-stemmer sont disponibles. Une classe d'emballage a été ajoutée pour chacun d'eux:
DanishStemmerDutchStemmerEnglishStemmerFrenchStemmerGermanStemmerItalianStemmerNorwegianStemmerNullStemmer (peut être utilisé pour désactiver le tige)PorterStemmer (par défaut, comme EnglishStemmer )PortugueseStemmerRomanianStemmerRussianStemmerSpanishStemmerSwedishStemmer Si vous avez des exigences différentes pour un STEMMER, vous pouvez fournir votre propre implémentation via la configuration. Assurez-vous simplement qu'il implémente l'interface Stemmer .
Le package suit les cas d'utilisation disponibles décrits dans la documentation officielle du Scout. Veuillez cependant être conscient des limitations énumérées.
Le pilote de recherche utilise en interne une seule table, qui contient des termes et l'association aux documents. Lors de l'indexation des documents (c'est-à-dire des modèles d'ajout ou de mise à jour dans l'index de recherche), le moteur utilisera le tokenizer configuré pour diviser l'entrée de chaque colonne en jetons. Le tokenzer configuré par défaut divise simplement les entrées dans des mots composés de toute lettre ou numéro Unicode, ce qui signifie tout autre caractère comme , . , - , _ , ! , ? , / , Whitespace et tous les autres caractères spéciaux sont considérés comme des séparateurs pour les jetons et seront supprimés par le tokenzer. De cette façon, ces personnages ne se retrouveront jamais dans l'index de recherche lui-même.
Une fois que les entrées ont été tokenisées, chaque jeton (et à ce stade, nous nous attendons en fait à ce que nos jetons soient des mots) est exécuté via la tige configurée pour récupérer la tige (c'est-à-dire le mot racine ). L'exécution de cette action nous permet de rechercher des mots similaires plus tard. Le PorterStemmer par exemple, produira intellig en tant que sortie pour intelligent et intelligence en entrée. La façon dont cela aide lorsque la recherche sera claire dans un instant.
Enfin, les résultats de ce processus sont stockés dans la base de données. Le tableau d'index est rempli des résultats du processus de tige et des associations avec les modèles indexés (type de modèle et identifiant). En plus de cela, pour chaque ligne de l'index, la base de données contient également le nombre d'occasions dans un document. Nous utilisons ces informations pour marquer dans la partie de recherche de notre moteur.
Lors de l'exécution d'une requête de recherche, le même processus de tokenisation et de tige utilisé pour l'indexation est appliqué à la chaîne de requête de recherche. Le résultat de ce processus est une liste de tiges (ou de mots racine ) qui sont ensuite utilisées pour effectuer la recherche réelle. Selon la configuration du package, la recherche renverra des documents qui contiennent au moins une ou toutes les tiges. Cela se fait en calculant un score pour chaque correspondance de l'indice en fonction de la fréquence de document inverse (c'est-à-dire le rapport entre les documents indexés et les documents contenant l'un des mots recherchés), le terme fréquence (c'est-à-dire le nombre d'occurrences d'un terme de recherche dans un document) et le terme écart (qui n'est pertinent que pour la recherche de wildcard). Les documents sont retournés par leur score dans l'ordre descendant, jusqu'à ce que la limite souhaitée soit atteinte.
Il est possible d'étendre la table d'index de recherche ( scout_index ) avec des colonnes personnalisées. Pendant l'indexation, ces colonnes peuvent être remplies de contenu personnalisé et lors de la recherche, les recherches peuvent être portée à ces colonnes (correspondance exacte). Cette fonctionnalité est particulièrement utile lorsque vous travaillez avec une application multi-tension où l'index de recherche est utilisé par plusieurs locataires.
Dans notre exemple, nous ajoutons une colonne obligatoire tenant_id à l'index de recherche.
return new class extends Migration {
public function up (): void
{
Schema :: table ( ' scout_index ' , function ( Blueprint $ table ) {
$ table -> uuid ( ' tenant_id ' );
});
}
public function down (): void
{
Schema :: table ( ' scout_index ' , function ( Blueprint $ table ) {
$ table -> dropColumn ([ ' tenant_id ' ]);
});
}
}; Le tenant_id est ajouté lors de l'indexation pour chaque modèle:
class User extends Model
{
public function toSearchableArray (): array
{
return [
' id ' => $ this -> id ,
' name ' => $ this -> name ,
' tenant_id ' => new StandaloneField ( $ this -> tenant_id ),
];
}
} Le tenant_id est filtré lors de la recherche en fonction du $tenantId , qui peut par exemple être tiré de la demande HTTP:
User :: search ( ' Max Mustermann ' )
-> where ( ' tenant_id ' , $ tenantId )
-> get ();De toute évidence, ce package ne fournit pas de moteur de recherche qui (même à distance) apporte les performances et la qualité d'un moteur de recherche professionnel comme les offres Elasticsearch. Cette solution est destinée à des projets de taille plus petite à moyenne qui ont besoin d'une solution assez simple à régler.
Il convient également de noter que les fonctionnalités de scout suivantes ne sont actuellement pas implémentées:
User::search('Mustermann')->within('users_without_admins')User::search('Musterfrau')->orderBy('age', 'desc')Un problème avec ce moteur de recherche est qu'il peut entraîner des problèmes si plusieurs travailleurs de file d'attente travaillent simultanément sur l'indexation d'un seul document (la base de données sera imprégnée). Pour contourner ce problème, un nombre de tentatives utilisées pour les transactions est configurable. Par défaut, chaque transaction est essayée un maximum de trois fois si une impasse (ou toute autre erreur) se produit.
La licence MIT (MIT). Veuillez consulter le fichier de licence pour plus d'informations.
