I just added laravel scout and configured everything as per documentation but when I just tested the query return \App\ProductData::search('')->get(); it returns me following error
AlgoliaException in Client.php line 992:
Index product_data does not exist
and I have no clue why this error is being generated. Moreover, I am not seeing any indexes or records in my algolia dashboard. Any help would be much appreciated.
Thanks
Have you correctly followed the instructions? You need to add a few things to your models in order to use Scout.
According to your error, algolia cannot find the model index. In ProductData, override the method from the Searchable trait:
public function searchableAs()
{
return 'product_data_index';
}
For those people who have this problem.
If you follow instruction on Laravel official hompage then successfully imported index and facing this error. Don't worry just because you've just imported index and Algolia hasn't finish it work. Wait for a while. If still can't, flush your index, restart your Laravel app and import Scout index again.
Enjoy :)
As Jan Petr suggests, it seems like you forgot to reindex your data first.
php artisan scout:import "App\ProductData"
After that you should see your data in Algolia's dashboard.
Related
I'm using Laravel and I'm wondering, is it possible to create a join, and then import that result as an Indice into Algolia for Searching? I know that Algolia imports models, so I'm not sure if there's a way this can be done. I'm using Laravel Scout and Algolia for search and Vue js for my front-end. This would solve the problem that I am having.
Thanks in advance.
You can try to customize the searchable data that is synchronized to Algolia by specifying toSearchableArray() method on the model. In that method, you can pass in the model and relation (whichever model you want to join with) data. More info:
https://laravel.com/docs/7.x/scout#configuring-searchable-data
I am using Laravel Scout + Algolia. We have reached our usage limit because every time someone visits a content page on our site I update the entry in the database to increment the page views counter. This then triggers Algolia to update, even though the page_views variable isn't even stored in Algolia. I am wondering if there is a way to update the database entry without triggering the Algolia update.
In the documentation there's a paragraph about that here.
Basically you can run a closure without syncing to Algolia in this way:
$currentInstance = 'your-model'; // This is the variable you want to inject
App\YourModel::withoutSyncingToSearch(function () use ($currentInstance) {
// Do the increment, and algolia indexing will not be updated
});
I have the following query which retrieves the child configuration records (confch) associated with the parent configuration (confp) and it works fine.
$data["items"] = Confp::find(decrypt($type))->Confch;
I just need to paginate the results.
adding ->paginate(10) would definitly not work as it does not exist in the resulting collection. I found nothing helping in the laravel documentation.
How can I do that please?
Try this instead of above code.
$confp = Confp::find(decrypt($type));
$data["items"] = $confp->setRelation('Confch',$confp->Confch()->paginate(10));
I want to rename an index in Laravel 5.
In a previous migration a column was created for table named a like so:
$table->unsignedInteger('foo')->index('blah');
I want to rename the index so that it uses the default Laravel notation.
i.e. I want to rename the blah index to a_blah.
I know how to rename a normal column, like so:
$table->renameColumn('from', 'to');
But the documentation does not mention how to rename indexes.
How can I do this?
UPDATE
It seems that Laravel does not support this natively. Please upvote the issue:
https://github.com/laravel/internals/issues/443
Laravel 5.6 now supports renaming indexes:
$table->renameIndex('from', 'to')
https://laravel.com/docs/5.6/migrations#renaming-indexes
Old Answer for Laravel <= 5.5
As #KuKec mentioned, it seems Laravel does not have native support for renaming indexes. But you can use raw SQL. For example in MySQL it would be like so:
DB::statement('RENAME INDEX old_index TO new_index');
This would also likely be more efficient than dropping and re-indexing (especially on large databases).
I have also created an issue for the feature request so this is better supported. Please upvote it here: https://github.com/laravel/internals/issues/443
I think Laravel doesn't support any method for renaming index, you should drop the old index blah
$table->dropIndex('blah');
and make new one with desired name a_blah.
$table->index('foo', 'a_blah');
You should first:
$table->dropIndex('your_full_name_index')
then do
$table->index('new_index_name')
After upgrading a Laravel project from 5.0 to 5.1.x, I can not run a composer update correctly.
The app itself works fine and no problems, but will need composer to work.
This is the error I am receiving after running sudo composer update
[LogicException]
The command defined in "Illuminate\Database\Console\Migrations\MigrateMakeCommand" cannot have an empty name.
Script php artisan clear-compiled handling the pre-update-cmd event returned with an error
[RuntimeException]
Error Output:
When trying to debug the file Illuminate\Database\Console\Migrations\MigrateMakeCommand I can not find any noticable error.
Any help would be greatly appreciated.
Laravel is giving its best to maintain the relationship first of all you need to have 2 model or you can say two table for relation and the respestive columns now you need to specify whether it has relation of one to one or one to many or many to many then you can simple specify it on model. As your tables are not specific tables so you can see the example like relation between users table and questions table relation here is one to many . One user can have many question while one question is belong to the user now In my Questions model the realtion looks like public function user() {
return $this->belongsTo('App\User');
}
now in the user model my code looks like
return $this->hasMany('App\Questions');
}
be sure you have maintained foreign key while migrating :) for more you can see here http://laravel.com/docs/5.0/eloquent#relationships hope this would help