Bug #86167
closed
Having a field in TCA but not in database makes the DatabaseIntegrityCheck crash
Added by Stefan P over 5 years ago.
Updated over 5 years ago.
Description
Ticket #79992 is somehow related.
sysext/core/Classes/Integrity/DatabaseIntegrityCheck.php line 443 throws a Null Pointer exception if a field is declared in TCA but not actually present in the database. I see two possible solutions here:
- only iterate over the intersection between TCA fields and actual database fields
- echo a note that there's a field declared that is not present and continue the loop with the next field
I prefer solution two, because it'd provide a nice check if there's some inconsistent/obsolete TCA configuration which should be fixed.
- Related to Bug #86092: Do not fetch type=none fields from db in list module added
- Status changed from New to Needs Feedback
Maybe it has been solved for you with #86092.
However how do you define the field in TCA? please add some code and explain (if not using type none) why there should be no related field in the DB. Thanks
I had the field fe_group in the columns section of some TCA files, but did not have the field in ext_tables.sql (because the table didn't use frontend authentification features). I know that this is actually a wrong configuration (good old copy-paste error) - but it seems only to fail in the DatabaseIntegrityCheck, that's how I noticed this behaviour.
#86092 has nothing to do with it (the list module works fine).
IMHO the DatabaseIntegrityCheck should actually check if a field is present in the database schema before accessing it and throw some kind of notice instead of just failing with a null pointer exception.
- Assignee set to Christian Kuhn
i'm fiddling in a similar area at the moment and can have a look at this case.
- Related to Bug #79992: Error in DB Check -> Database Relations added
I'll push a patch to prevent the crash.
A check to verify TCA and ext_tables.sql are in sync should not belong to this module, though. imho, the entire db check / lowlevel thing needs rethinking, we may eventually do that with v10 (v9 is feature frozen already). Thus for now, I think it is enough to prevent the crash and further work on this topic in a future core version.
- Status changed from Needs Feedback to Under Review
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Under Review
- Status changed from Under Review to Resolved
- Status changed from Resolved to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by