In my opinion you could also use ->lazy() instead of ->get() when querying the users - it sacrifices a runs a little bit slower for huge memory savings.
Everything looks good and Good Knowledge Sharing, But if there is many records in users table then you can use chunk insert instead of fetch all the records at the time - Its my opinion
so your part about caching the date I would never have thought of. Mainly cause I haven't thought about caching at all as Im still trying the get the other parts figured out. But I always assumed I would eventually just set up caching for whole pages that dont have to change all that often. I never really considered caching small pieces of data like this for optimization. So if you dont already have a video on this, perhaps you could make one that could explain different scenarios in which various levels of caching would help optimize an application.
@@LaravelDaily Thanks, its not as easy to search individual channels on mobile, but I also am not really in need of the topic personally at this time, Just wanted to provide a suggestion since you have asked for video ideas before, and I know you cover topics in different ways at times as there are many different ways topics can be implemented. This video prompted a question I thought may be worth diving deeper into, so I offered the suggestion. But i'll "cache" the response for future reference. I've got to go figure out how to use google ad manager
Hi, here could be a refactoring issue, "attendances" is HasToMany relation, so join can produce more than one user entity and we will get extra items in result $data array, this can cause data inconsistency or something else.
Why is this doing DB access and business logic in one function? How will you write tests for that command if you cannot mock the Holiday:: and User:: object, or even the business logic? What's the purpose of Day::sunday->name if it already has the name "sunday"?
Valid points, making this artisan command testable would mean a strong refactoring. Maybe you would want to perform it? I would gladly shoot a video about it.
@@LaravelDaily Hey! I don't see the purpose a command having a test written for it as it's just to coordinate operations. My thinking here is the business logic should be in its own class and injected into the command constructor. Then the Holiday:: + User:: object are injected into the business logic class. A test is then written for the business logic class to lock down its functionality.
Hi, I have a question about deleting "second degree relationships." Lets say I have a grandparent->children->grandchildren and when I delete a grandparent, my goal is to delete its children and grandchildren. I'm not sure if there is a good, standard solution, but here is ChatGPT's working solution: // Grandparent.php (the function is utilized in the GrandparentController.php when deleting) public function deleteWithRelated() { // Delete grandchildren $this->grandchildren()->each(function ($grandchild) { $grandchild->delete(); }); // Delete children $this->children()->each(function ($child) { // Delete children $child->delete(); }); // Finally, delete the grandparent $this->delete(); }
I would personally do it on the database level, in migrations: $table->foreignId()->constrained()->cascadeOnDelete(); But if you don't have that in the database, then yeah, I guess ChatGPT solution is ok.
Following up, I've just published this tutorial. Laravel Parent Children and Grandchildren Delete: Three Options laraveldaily.com/post/laravel-parent-children-grandchildren-delete-records
In my opinion you could also use ->lazy() instead of ->get() when querying the users - it sacrifices a runs a little bit slower for huge memory savings.
Everything looks good and Good Knowledge Sharing, But if there is many records in users table then you can use chunk insert instead of fetch all the records at the time - Its my opinion
this is great sir, thanks for always enlightening us.
It would be good to run explain on the raw sql queries and checking for any full table reads. Then add indexes as needed to optimize those queries.
so your part about caching the date I would never have thought of. Mainly cause I haven't thought about caching at all as Im still trying the get the other parts figured out. But I always assumed I would eventually just set up caching for whole pages that dont have to change all that often. I never really considered caching small pieces of data like this for optimization. So if you dont already have a video on this, perhaps you could make one that could explain different scenarios in which various levels of caching would help optimize an application.
Searched "caching" on the channel for you: www.youtube.com/@LaravelDaily/search?query=caching
@@LaravelDaily Thanks, its not as easy to search individual channels on mobile, but I also am not really in need of the topic personally at this time, Just wanted to provide a suggestion since you have asked for video ideas before, and I know you cover topics in different ways at times as there are many different ways topics can be implemented. This video prompted a question I thought may be worth diving deeper into, so I offered the suggestion.
But i'll "cache" the response for future reference. I've got to go figure out how to use google ad manager
Good quistion
just learned bout it too
@@LaravelDaily I want laravel 11 VS Flutterwave
The only addition I would do is add pagination logic so that if I have many employees the command will continue working without any changes.
This is very useful, thank you
I believe you can check if date is during the weekend via Carbon instance method
With the query change, you'll also need to update the data side as shift end_at won't be on a relation.
Yes great point
Hi, here could be a refactoring issue, "attendances" is HasToMany relation, so join can produce more than one user entity and we will get extra items in result $data array, this can cause data inconsistency or something else.
Technically, you're right. But I guess those extra items could be identified and filtered out with where() conditions.
I only use model query if I actually want to get the model, otherwise I'm just doing a DB::table('***') query
Why is this doing DB access and business logic in one function? How will you write tests for that command if you cannot mock the Holiday:: and User:: object, or even the business logic? What's the purpose of Day::sunday->name if it already has the name "sunday"?
Valid points, making this artisan command testable would mean a strong refactoring. Maybe you would want to perform it? I would gladly shoot a video about it.
You can still make feature tests for this command.
@@LaravelDaily Hey! I don't see the purpose a command having a test written for it as it's just to coordinate operations.
My thinking here is the business logic should be in its own class and injected into the command constructor. Then the Holiday:: + User:: object are injected into the business logic class.
A test is then written for the business logic class to lock down its functionality.
Hello sir,
User()->query()
The Meaning is instence to model user for elequent?
What a benefit to used?
Thanks for education us with this video
This video is the answer: th-cam.com/video/yviVaX7-wT4/w-d-xo.html
Very nice but shouldn't weekend be sunday and saturday?
Not in all countries of the world
Is it big "NO" to use DB queries in helper functions or should I cache daily for example to convert currency?
It depends on the situation, there's no single answer.
Nice🥰
i need to email your sir
Hi, I have a question about deleting "second degree relationships." Lets say I have a grandparent->children->grandchildren and when I delete a grandparent, my goal is to delete its children and grandchildren. I'm not sure if there is a good, standard solution, but here is ChatGPT's working solution:
// Grandparent.php (the function is utilized in the GrandparentController.php when deleting)
public function deleteWithRelated()
{
// Delete grandchildren
$this->grandchildren()->each(function ($grandchild) {
$grandchild->delete();
});
// Delete children
$this->children()->each(function ($child) {
// Delete children
$child->delete();
});
// Finally, delete the grandparent
$this->delete();
}
I would personally do it on the database level, in migrations: $table->foreignId()->constrained()->cascadeOnDelete();
But if you don't have that in the database, then yeah, I guess ChatGPT solution is ok.
Following up, I've just published this tutorial.
Laravel Parent Children and Grandchildren Delete: Three Options
laraveldaily.com/post/laravel-parent-children-grandchildren-delete-records