I'm building a system to manage some articles for my company using Laravel and Laravel Scout with Algolia as the search backend.
One of the requirements states that whenever something in an article is changed, a backup is kept so we can prove that a certain information was displayed at a specific time.
I've implemented that by cloning the existing article with all its relationships before updating it. Here is the method on the Article model:
public function clone(array $relations = null, array $except = null) {
if($relations) {
$this->load($relations);
}
$replica = $this->replicate($except);
$replica->save();
$syncRelations = collect($this->relations)->only($relations);
foreach($syncRelations as $relation => $models) {
$replica->{$relation}()->sync($models);
}
return $replica;
}
The problem is the $replica->save() line. I need to save the model first, in order for it to have an ID when syncing the relationships.
But: The only thing preventing scout from indexing the model is if the model has its archived_at field set to any non-null value. But since this is a clone of the original model, this field is set to null as expected, and is only changed after the cloning procedure is done.
The problem: Scout is syncing the cloned model to Algolia, so I have duplicates there. I know how to solve this, by wrapping the clone call into the withoutSyncingToSearch (https://laravel.com/docs/5.6/scout#pausing-indexing) callback.
But since this is rather important and the bug is already out there, I want to have a unit test backing me up that it was indeed not synced to Algolia.
I don't have any idea how to test this though and searching for a way to test Scout only leads to answers that tell me not to test Scout, but rather that my model can be indexed etc.
The question: How do I create a Unittest that proves that the cloned model wasn't synced to Algolia?
At the moment I'm thinking about creating a custom Scout driver for testing, but it seems to be a total overkill for testing one single function.
Related
I'm currently utilizing Laravels notification package a bit more, but the following bothers me for weeks now: What should I really store in notifications?
Sometimes notifications are related to specific models, but not always.
Examples: Your blog post was published. or An error occurred while doing something. The entry was deleted.
Sometimes these models have relationships like Post → Category and the message should look like: Your blog post in the category "A Category" was published.
Now the questions:
Should I save a related model completely (eg. Category)? This would make accessing it later easier, but it's also a source for inconsistency. Or should I simply save the category ID? Only saving the ID means that I can reference the current data, but what happens if the category gets deleted? Then the notification cannot be rendered. Also I would need to also query the related models for this notification everytime.
Should I save the full message or only the data and compose the message on the client? (App, SPA Web-Frontend...). What about localization then?
What is a best practice for future scaling and also for extending existing notifications in the future?
So you propose to either go for:
1. Save notifications including all data required to display it
OR
2. Save notifications with just references so it can render message later on
So let's consider the advantages and drawbacks of both options.
Option 1: saving including all data
If a related model is deleted, the notification message can still be rendered as before (as you mentioned)
If a related model is changed (e.g. category title is changed), the notification message does not change
If you want to change a notification later on to include additional fields from related models, you won't have those fields available
Option 2: saving including just references
If a related model is deleted, the notification can not be rendered (as you mentioned). I would however argue that the notification wouldn't make much sense in this case.
If a related model is changed (e.g. category title is changed), the notifciation message changes with it
If you want to change a notification later on to include additional fields from related models, you will have those fields available
Additionaly if you were to serialize the notifications in the database you won't be able to deserialize them if you changed the model for it later on (e.g. a field is deleted).
Implementation of option 2
In order to go for option 2 additional database load can't really be avoided.
Easy way
The easiest way would be to resolve the relationships in the notification would be to query the relationships during the rendering of the notifications array, this however will cause the system to an additional query for each relationship.
NotificationController.php
$user = App\User::find(1);
foreach ($user->notifications as $notification) {
echo $notification->type;
}
MyNotification.php
public function toArray($notifiable)
{
$someRelatedModel = Model::find($this->someRelatedModel_id);
return [
'invoice_id' => $this->invoice->id,
'amount' => $this->invoice->amount,
'relatedModelData' => $someRelatedModel->data,
];
}
Nicer way
The better solution would be to adjust the query currently used for retrieving the notifications so it will include the relationships on the initial load.
NotificationController.php
$notification = App\Notification::byUserId(1)->with('someRelatedModel);
See eager loading for more on this.
Tl;dr Considering the points above I'd go with option 2; only keep references to models you'll need when rendering the notification.
I'm working on a Laravel project and I'm using https://laravel.com/docs/5.3/scout with ElasticSearch on a model Offer.
I already have some offers in my database, so I just run the command
`php artisan scout:import "App\Models\Offer"`
for generate the index for use my datas with ElasticSearch.
After that it's ok, I can search in my offers with, for example :
`$offers = Offer::search($request->keywords)->get();`
Now I have a function for create other offers in my database, and I dont know how can I refresh the index for use these new datas ?
In the documentation https://laravel.com/docs/5.3/scout#adding-records, I can read
all you need to do is save a model instance and it will automatically be added to your search index
I tried this and no, when I save() a new Offer, I can't find it in my index.
I tried to re run the command php artisan scout:import "App\Models\Offer" after add anew OFfer, but it's the same, I can't find it in my index.
Did I miss something ? Any ideas ?
Sorry for a late response on this but I ran into this issue myself when I attempted to use Scout. Everything went fine until I realized that the project's data would scale at a rate that went far beyond what scout could handle. In this case, however you can use the push() method instead of save(). I'm not sure why this isn't documented at all and it's rather frustrating but there's an answer at least.
So use:
->push()
instead of:
->save()
to update your indexes.
If that does not work for your specific version there is another way you can do it but it is "slightly" redundant. It involves a mix of using the queue system with the Artisan system and a command. In this you:
Create a queue/job php artisan make:job JobNameHere (As of Laravel 5.2 - 5.4)
Add use Artisan; to the top of that newly created Job Class so you can pull in the Artisan's functionality
In the handle of that Job Class add
class JobNameHere implements ShouldQueue {
...
...
public function handle() {
Artisan::call('scout:import', ['name' => "App\YourModelNameHere"]);
}
}
Add a dispatch call to that job class right after your DB push() process is called.
Example:
class YourController extends Controller {
public function yourUpdateMethod(Request $request) {
//Some code you wrote
//Some more code you wrote
$update_obj->push( $array_to_update_obj);
dispatch(new JobNameHere());
}
}
Test your index by searching on it
If all went well then you should no longer get any errors. Please leave a comment and let me know how it went... provided you're still having this issue.
I would also like to mention that Laravel Scout does not support ElasticSearch anymore as of August of 2016 (I believe). No one really knows why the support was removed but there are a few tutorials out there to help you get Laravel and Elastic search working together again.
I will also note, based on my research, that if your project is small then you should be fine to use Scout and not need to use ElasticSearch. If your project is going to get huge, then you're probably better off finding a package that supports and well documents how handle Laravel's relationships between models. Elastic search is capable of accomplishing this but there are tons of docs that make figuring it out difficult. Here are some semi-decent tutorials to help get you going down the right path.
https://tirdeamihai.com/blog/laravel-and-elasticsearch
https://laravel-news.com/laravel-and-elasticsearch
Plastic is a package that I would currently recommend as it's being actively worked on. Elasticquent hasn't been touched or updated since last year in June.
https://github.com/sleimanx2/plastic#1---create-a-new-index
I was trying to get this working in a typical belongsTo relation. However it keeps saying that the column is not set in the model, even if looking in the actual database it is there.
I have tried to look at the source code as well as try many approaches to bypass this issue, however nothing seems to do anything.
public function modifiedBy()
{
return $this->belongsTo('\Modules\Users\Model\User', 'modified_by');
}
public function createdBy()
{
return $this->belongsTo('\Modules\Users\Model\User', 'created_by');
}
This is the code inside the model, I use PSR-0 to define modules, better splitting up logic (no issues with that) but using this it would give an error of
Undefined property: \Modules\Module\Model\CurrentModel::$modified_by
This is coming from a seed to push some initial info into the database.
$user = Sentinel::findById(1);
$model = new CurrentModel;
$model->modifiedBy()->associate($user);
$model->save();
This is basically how it goes together, I have tried for some time to figure out what is wrong but I am calling blanks. Any ideas?
Found out a solution. Not a fix though but I would consider this an issue with laravel so I may look into adding it as a bug report (although this could be fixed in laravel 5?).
Basically with modified_by I need to define the column it is using and not let laravel automatically generate it (in order to do this "cleanly"). However the "bug" (only calling it a bug as currently I can only see this as an unintended problem) makes it so you cannot define the column it will be using, you have to let laravel decide it for you.
So I changed the functions to look like this:
public function modifiedby()
{
return $this->belongsTo('\Modules\Users\Model\User');
}
This makes laravel assume the column is modifiedby_id, but by changing my migrations to reflect that there was no more error.
I wanna move the business logic out of controller actions. I read a lot about repository pattern in laravel with tons of examples.
However they're usually pretty straightforward - we have a class that uses some repository to fetch a list of all possible records, the data is returned to the controller and passed to the view.
Now what if our list isn't all the possible records? What if it depends on many things. For example:
we display the list as "pages" so we might need X records for Y-th page
we might need to filter the list or even apply multiple filters (status, author, date from - to etc)
the user can change the sorting of the data (for example by clicking the table column titles)
we might need some data from other data sources (joined tables) or it might even be used for sorting (so lazy loading won't work)
Should I write a special method with all these cases in mind? Something like that:
public function getForDisplay(
$with = array(),
$filters = array(),
$count = 20,
$page = 0,
$orderBy = 'date',
$orderDir = 'DESC'
)
{
//all the code goes here
return $result;
}
And then call it like this from my controller:
$orders = $this->orders->getForDisplay(
array('customer', 'address', 'seller'),
Input::get('filters', array()),
20,
Input::get('page', 0),
Input::get('sort', 'date'),
Input::get('direction', 'DESC')
);
This looks wrong already and we didn't even get to the repositories yet.
What are the best/correct practices for solving situations like this? I'm pretty sure there has to be a way to achieve the desired results without adding all the possible combinations as a method arguments.
Use the repository pattern just for business model updates and you'll end up with very specific query methods (the Domain usually doesn't need many queries and they are pretty straightforward). For UI/reporting querying purposes, you can use a simple DAO/Service/ORM/QUery Handler , that will take some input and returns the desired data (at least part of the view model).
Since you're already using an ORM, you can use it directly. Note that you can use the ORM for domain updates also, but inside a repository's implementation i.e the app only sees the repository interface. We care about separation at the business layer, for UI querying you can skip the unneeded abstraction.
Btw, because we're talking about design, everything is subjective and thus, there's no single best/optimum way of doing things.
I'm trying to find all users w/ a specific permissions list in Sentry with laravel. The problem is that Sentry::findAllUsersWithAccess() returns an array().
as stated in their github repository i pinpointed their code to be
public function findAllWithAccess($permissions)
{
return array_filter($this->findAll(), function($user) use ($permissions)
{
return $user->hasAccess($permissions);
});
}
right now, it gets all users and filter it out with users with permission list. the big problem would be when I as a developer would get the set of users, it'll show ALL users, i'm developing an app which may hold thousands of users and i only need to get users with sepcific permission lists.
With regards to that would love to use one with a ->paginate() capability.
Any thoughts how to get it without getting all the users.
Why dont you override the findAllWithAccess() method and write your own implementation, which uses mysql where instead of array_filter().
I dont know your project structure and the underlying db schema, so all i can give you atm is the link to the eloquent documentation Querying Relations (whereHas).
In case you dont know where to start: its always a good idea to look at the ServiceProvider (SentryServiceProvider, where the UserProvider, which holds the findAllWidthAccess() method, is registered). Override the registerUserProvider method and return your own implementation of the UserProvider (with the edited findAllWithAccess() method).
Hope that will point you in the right direction.
In Laravel you can do pagination manually on arrays:
$paginator = Paginator::make($items, $totalItems, $perPage);
Check the docs: http://laravel.com/docs/pagination