* BUGFIX many many through not sorting by join table
* #8534 added docs to support many many sorting fix
* #8534 added test cases for many_many default sorting
Some small performance optimisations (not using callables in loops, switch strval for string
casting), Config call updates and replace call_user_func_array with direct variadic call.
Also removes some redundant else statements after returns.
This makes it easier to swap one fo the other without code breaking.
Since it’s strictly a removed API, I’ve opted to throw a deprecation
note in SS4 rather than throwing an InvalidArgumentException.
Fixes#2949
Note that the medium date format depends on locale, with en_NZ being
resolutely numeric. I’ve updated the test to verify a couple of locales
to make this more obvious.
Fixes#8121
The SS4 behaviour of limit=0 is unlikely to be the SS5 behaviour.
To clear the limit limit=null is recommended.
In addition, there’s a bit tighter type maintenance in the internal
limit data (ensure things are int).
Fixes#2950.
clearTable is mainly used for clearing data between tests. In this case,
there are very few or zero records, and DELETE FROM is quicker than
TRUNCATE, which works by deleting and recreating the table.
This materially speeds up test execution, at least on MySQL.
Cherry-pick of SS3 ae9ab22a8f
clearTable is mainly used for clearing data between tests. In this case,
there are very few or zero records, and DELETE FROM is quicker than
TRUNCATE, which works by deleting and recreating the table.
This materially speeds up test execution, at least on MySQL.
Implemented in SS3 at 815da76b056a716c8831d22bbf93528912cbcb28
This prevents the map-to-ArrayData conversion from changing object
state and making the result of toArray() non-deterministic.
Fixes#2636. Other solutions were suggested on that ticket, but there is
no way of putting special code in for a SSViewer-specific iterator, and
having object state pre-emptively converted to ArrayData would
be an SS5-level change.
* NEW: Add Hierarchy::prepopulate_numchildren_cache()
API: Hierarchy::stageChildren() customisations must be applied to the base class and not include record-specific behaviour.
Adds the ability to prepopulate the cache for Hierarchy::numChildren()
in a batch.
Note that this optimisation means that stageChildren() is not called on
each record in order to calculate numChildren(). This means that the
structure of the stageChildren() query must be the same for all records
and the behaviour cannot be customised only for a subclass of the base
data class. For example, apply your customisations to SiteTree and not
a subclass.
This is an useful part of optimising the query count on tree generation.
See https://github.com/silverstripe/silverstripe-framework/issues/8379
* NEW: Add Hierarchy::prepopulateTreeDataCache()
This provides a more extensible way of preopulating caches for optimised
tree generation.
Fixes https://github.com/silverstripe/silverstripe-framework/issues/8391
This variant of showqueries will include a backtrace after each query.
This is extremely verbose but can be helpful when diagnosing where
queries have come from.
This is something that I have frequently added as a local hack on my
environment, I figured that exposing it as a formal feature would be
useful.
