silverstripe-framework: BUG: defaults are not inherited in SS3
Affected Version
3.7.1
Description
Basically we have this:
ParentClass extends DataObject
{
private static $db = [
'FieldA' => 'Boolean'
];
private static $defaults = [
'FieldA' = 1;
];
}
and
class OtherClass extends ParentClass
{
}
When we create an object of the OtherClass type then FieldA is set to FALSE. We would expect this to be TRUE because that is the default. We tried both “true” and “1” as default values.
From what I know about Silverstripe this is not correct AND worked differently before AND if correct, has a massive impact.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 16 (16 by maintainers)
Commits related to this issue
- FIX: Injector services being cached without 'type' set (fixes #8567) — committed to kinglozzer/sapphire by kinglozzer 5 years ago
- FIX: Injector services being cached without 'type' set (fixes #8567) — committed to kinglozzer/sapphire by kinglozzer 5 years ago
- FIX: Injector may instantiate prototypes as if they're singletons (fixes #8567) — committed to kinglozzer/sapphire by kinglozzer 5 years ago
- Merge pull request #8747 from kinglozzer/defaults-i-got-em-from-my-momma-class FIX: Injector may instantiate prototypes as if they're singletons (fixes #8567) — committed to silverstripe/silverstripe-framework by robbieaverill 5 years ago
Fixed with #8747 (merged up to 3)
I think this is the most welcoming approach. Obviously some moderately sized (but not critical) bug we can say we’re not accepting it because taking the time to code review and test it will be substantial. But simple fixes that take ~15 minutes to review/test I think we should still be receptive.
If the author abandons it though we can just close it.
Sorry about the slight side-track in this - perhaps this discussion can happen elsewhere
I don’t think it’s a simple “yes” or “no” case – I think it comes down to a tradeoff of how critical the bug is vs the risk of introducing it. The fact that the PR comes from a long-standing core committer carries weight. Suggest the discussion happens on the PR.
Also – is this broken or fixed in SS4?