Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
FIX #2174: SearchFilter needs casting helper for DataObject base fields
Commit 964b3f2 fixed an issue where dbObject was returning casting helpers for fields that were not actually DB objects, but had something in $casting config. However, because dbObject was no longer calling DataObject->castingHelper, this exposed a bug that the underlying function db($fieldName) was not returning field specs for the base fields that are created by SS automatically on all DataObjects (i.e. Created, LastEdited, etc). This commit fixes the underlying issue that DataObject->db($fieldName) should return the field specs for *all* DB fields like its documentation says it will, including those base fields that are automatically created and do not appear in $db.
- Loading branch information
1 parent
429bbc5
commit 50e9eee
Showing
4 changed files
with
82 additions
and
18 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -300,4 +300,4 @@ protected function getCaseSensitive() { | |
else return null; | ||
} | ||
|
||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
50e9eee
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.
I think since this commit, Created/LastEdited/ID/ClassName are showing up in my dataobjects in my modeladmin.
50e9eee
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.
Yeah, this has broken VirtualPageTest too.
This shouldn't really have been merged into 3.1 this late in the cycle. It changes how DataObject#db functions, but there are lots of calls to that method that assume the old behaviour & break on the new one. I'm probably going to at least partially revert it for now.
50e9eee
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.
@hafriedlander give me a few minutes to work on this ... it all goes back to #2021. I still think that the commits for that issue and this one were the correct thing to do (made things work as their docs said they should), but since the way they were implemented is what's breaking things, I think at the very least we can make a safer change to DataObject->db (for #2021) but not make the changes in this commit, and still make all the test cases pass.
50e9eee
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.
Sure, take a look. I'm looking too, since the CMS tests breaking is holding up a pretty critical fix.
Possibly, although the docs are definitely not a canonical source for correct operation - they're often overlooked when changing methods. The issue is basically, we shouldn't be making API changes at this stage unless absolutely critical, and changing db like this is an API change.
PS you didn't used to be able to overwrite the Created date like you do in your test - it was forced as part of the write process. Not sure if that changed before & I just didn't notice, or is also an artefact of this patch.
50e9eee
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.
@hafriedlander see #2187 which reverts all the changes I made and fixes the original problem a different and much less obtrusive way. It leaves all the additional test cases I wrote, thought, since they are still valid.
If that's the case it must have changed well before my commits because the test case still passes even after reverting my other changes. Seems like maybe we should create an issue for it so somebody can dig into it later. In that case the test case will need to be modified to still work (maybe direct DB update query) so that we can easily still test the use case that caused me to write the test in the first place. But for now it's a useful test (testing querying by Created).
50e9eee
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.
f2a709d is the commit that added that behaviour. Was designed so you could write unit tests that used Created.
50e9eee
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.
Cool, mystery solved.