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.
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.
When selecting a column, it doesn't make sense to have it distinct.
As an alternative, the API could be changed to give the end user the option
(eg `->column($field, $distinct = false)`)
However if we did that, we would need to make sure we do something
similar with `SilverStripe\ORM\UnsavedRelationList` to ensure consistency.
