-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New methods: BaseActiveRecord::loadRelations() and BaseActiveRecord::loadRelationsFor(). #19893
Conversation
PR Summary
|
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #19893 +/- ##
=======================================
Coverage 48.94% 48.95%
=======================================
Files 445 445
Lines 42817 42826 +9
=======================================
+ Hits 20956 20964 +8
- Misses 21861 21862 +1
☔ View full report in Codecov by Sentry. |
Would you please add tests for the method? |
Done. |
public static function loadRelationsFor(&$models, $relationNames, $asArray = false) | ||
{ | ||
// ActiveQueryTrait::findWith() called below assumes $models array is non-empty. | ||
if (empty($models)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not if (!empty($models))
and avoid empty return
statement which raises Codecov warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will make the code less readable IMO:
- your variant uses extra logical operator (which makes expression more complex for human understanding);
- the ! operator is easily missable at a glance;
- my variant has a clearly visible useful work of a function (last line) and a clearly separated condition when it can be skipped; your variant would have these tangled up making it harder to understand what is the normal function flow and what are the exceptions in it.
Making the code less readable just to shut up a warning in some imperfect external tool is a bad idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But shouldn't it cover the test, for when the model is empty?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But shouldn't it cover the test, for when the model is empty?
You mean if there should be a test for a loadRelationsFor([], /*...*/)
call? I don't think this test will be very useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it is testing the code, in the case that the model is empty.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it is testing the code, in the case that the model is empty.
So you just want to do the testing for the sake of doing testing even if it doesn't test anything useful at all? If you disagree, please show us how such test could possibly look and explain its usefulness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@PowerGamer1 when things breaks for empty models with some bug in the code (let say someone else modified your now empty return to something else, how will we detect it? That's where this test comes to rescue. Currently sound like useless, but it will make code "future proof" sort of!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@PowerGamer1 ... let say someone else modified your now empty return to something else, how will we detect it?
At present, testing a single return statement is useless. If, in the future, as you say someone replaces/modifies this return statement with a MORE COMPLEX piece of code - then at that point in time testing such MORE COMPLEX piece of code might become warranted. Obviously, testing of such (currently non-existent) more complex code path should be done when it is introduced by the person who introduced it.
Also, if I were you (i.e. engine maintainer), I would be much more concerned with testing infinitely more complex and currently completely untested pieces of code (such as ActiveQueryTrait::findWith()
and myriad others). In fact, the only reason I am currently writing any tests at all is the fact that new shortcut methods rely on such untested functionality - i.e. I don't really test NEW code, I have to test already EXISTING code.
P.S. That test you want me to write - have you even imagined how exactly it will look? What exactly are you going to assert (like assertTrue()
etc.) in it?
No such reliance on the Customer::find()->with('orders.items')->all(); That example above works without defining inverse relation and so do new methods which you can see in the tests (neither |
@PowerGamer1 Yes, when I dived deeper into it I came to the same conclusion and removed my comment. But your response beat me to it 😄. |
@PowerGamer1 All good. Would you please resolve conflicts so I can merge it? |
Done. |
Please resolve the conflicts so I can hit the merge button. Thanks. |
1 similar comment
Please resolve the conflicts so I can hit the merge button. Thanks. |
@samdark Conflicts resolved. |
Damn :( Conflicts again. @PowerGamer1 need your help. |
ba168ec
to
9e3595f
Compare
You might want to merge this soon as I will not be able to rebase this commit to latest master for much longer (as I will be leaving github due to forced 2FA policy). |
@PowerGamer1 could you resolve conflicts one more time? I'll merge this immediately after. Sorry for the long time waiting. |
…loadRelationsFor().
@bizley No worries, conflicts resolved. |
Thank you. Sorry to hear you are leaving GH. |
I'm wandering, is this support nested relationship like dot notation |
Equivalent of https://laravel.com/docs/10.x/eloquent-relationships#lazy-eager-loading in Eloquent ORM.
Should be mentioned in Yii2 guide.