Don't fetch eager-loaded has_many or many_many unless we've validated
that the relation IS actually a has_many or many_many relation.
Also clear eager-loaded relations when flushing the record.
Add tests for:
- filtered, limited, and sorted DataLists with eagerloaded relations
- iterating through the list multiple times
- eagerLoad method can be called anywhere in a query chain
- eager loaded relation lists can be correctly empty without throwing
exceptions
- repeating relations to be eagerloaded in various permutations doesn't
cause issues
- eagerloading doesn't negatively impact chunkedFetch functionality
squash
Includes making sure toArray() uses the correct iteration logic,
and cloning resets the eagerloaded data for the new clone.
Previously, a second iteration would add every relation item to the
relation list a second time - so with each iteration your relation list
count doubled (though it was the same records time and again).
* FIX PHP 8.1 support in MySQLiConnector::query errors
The default error reporting mode in PHP 8.1 has changed from using
errors reported on the connection handle to throwing
mysqli_sql_exception. query() makes no allowance for this, and
functions up the call stack expect to catch
Silverstripe\ORM\Connect\DatabaseException instead - resulting in the
MySQLi exception going all the way up to halt the system.
We can use a try, catch, and finally to retain backwards compatibility,
no matter which setting (e.g. PHP version default) someone has enabled.
* Move MySQLConnector test skip call into setUp()
As review feedback; marking the test as skipped in a private function
obfuscated where the call was happening and made it harder to skimread
the tests. Moving this into a setUp function makes it obvious the check
is run before each test case, and skipped if necessary.
It is hard to work with the current structure - having each relation
type in its own method makes it way easier to see where my concerns
start and end with a given relation.
This also reduces the chance of variable bleed-over, where the value in
a variable in the first loop (in the same or other relation type) could
bleed into the next iteration of the loop.
