you could replace any hasOne with hasMany.B hasOne C and C belongsTo B (foreign key b_id in C's table).A hasOne B and B belongsTo A (foreign key a_id in B's table).
#ELOQUENT RELATIONSHIPS JOIN UPDATE#
Not the guy, but I guess forgetting to update the extra duplicated foreign key. How would you all handle this situation? And what would you add to this discussion in order to educate younger devs about the nuance of eloquent queries vs. So you would need to do this:īut now we are back in the same situation where we are potentially pulling in thousands of records to do something very simple. The collection is needed in order to access the attribute. So it is not available on posts() through eloquent. Why does it fail? Because comments() is a relationship which is treated like an attribute by Laravel. We should always avoid pulling in large collections just to sort them, even on an attribute.Īnother caveat is that this process of only using eloquent instead of collections only applies to a single level of relationship. So how do we handle those scenarios? I would say that's a point of discussion and there's no simple answer without using DB raw statements, which sometimes are the best solution. This is a great principle, but can prove difficult to do in practice because you sometimes need to sort the entire collection by an attribute's value, but you can't do that unless you literally pull in the entire collection of objects first. If we find ourselves in this type of situation, the important thing to remember is to try and always LIMIT the scope of the query, so we aren't unnecessarily pulling in more records than we need to.
For instance, what if we want to use a where statement on an appended attribute? The only way to do this would be to pull the models into memory and then use collection sorting, since the attribute has to be "printed" outside of the database. For these types of cut and dry examples, it's obvious why we would want to use the former instead of the latter.īut there are caveats. A little CPU usage, but nothing is pulled unnecessarily.
The second, and more performant option, solves this by simply performing a database count of the rows associated with user posts. You're talking about a huge potential memory issue here, where we are filling up our RAM with completely unnecessary collection bloat. Especially if the posts themselves have comments, and those are appended and brought along for the joy ride. The overhead required here for a user that has, say 10,000 posts, is enormous. In the first case, ALL of a user's posts are pulled into memory as a collection, and then counted. This is a subtle difference and one that seems to be overlooked without proper training, and even forgotten when you don't focus on it as an important part of our understanding of Laravel. $user->posts()->count(): //How we all should do it
$user->posts->count() //How my junior dev did it Example below to get a user's post count:
One thing I found was a constant use of collections of a relationship rather than the eloquent query builder version, which can have a significant negative impact on server performance.
#ELOQUENT RELATIONSHIPS JOIN CODE#
For anybody that is new to Laravel and Eloquent, or even for those of us that have been using it a long time, I've come across something in one of my junior dev's code that reminds me that we often need to brush up on base concepts in order to improve overall app performance.
0 kommentar(er)
