TYPO3 Core

• tt_content.loginstatusredirect_status
• tt_content.loginstatusredirect_pid

MySQL version 5.5.33 on Mac OS X 10.9.2

Please do not link the images but upload them here directly.

EXT:loginstatusredirect

CREATE TABLE tt_content (
  loginstatusredirect_status    varchar(3) NOT NULL DEFAULT 'in',
  loginstatusredirect_pid        int(10) NOT NULL DEFAULT '0'
);

Hm, I applied that in a demo extension here, but the compare database does not complain.
The fields exist and obviously they are properly identified to exist by the Core.

Something is weird with your database somehow, since the analyzer always has the impression that these fields are not present in the db.
I can not help you here, sorry, you need to debug why the fields are not detected.
Maybe someone else is able to reproduce this, I only have Fedora and MariaDB at hand.

Thanks for taking the time to report!

Thanks, Markus.

I have the same problem in another site, with different tables. Seems like TYPO3 doesn't understand the additional key specification.

ALTER TABLE tx_kestats_cache DROP KEY whereclause_index;
ALTER TABLE tx_kestats_cache ADD KEY whereclause_index (whereclause(260),orderby(20),groupby(20));

EXT:ke_stats/ext_tables.sql:

[...]
#
# Table structure for table 'tx_kestats_cache'
#
CREATE TABLE tx_kestats_cache (
        uid int(11) NOT NULL auto_increment,
        whereclause text NOT NULL,
        orderby text NOT NULL,
        groupby text NOT NULL,
        result longtext NOT NULL,

        PRIMARY KEY (uid),
        KEY whereclause_index (whereclause(260),orderby(20),groupby(20))
);
[...]

(this one's on a Debian machine)

I knew this kind of problems, but I did not experience these issues for a long time now. Maybe there's some crucial database setting that causes this, which we don't know of yet.
It would be really interesting what information the DatabaseSchemaMigrationService gets from the database. If you have the possibility to debug this, it would be awesome.

Markus Klein wrote:

If you have the possibility to debug this, it would be awesome.

Sure, I'd be happy to. Could you give me some instructions on how to do this?

Sorry, I can't give you a full how-to on debugging PHP here. There are just way too many ways and too many possible system setups.
Please consider finding a tutorial on the web matching you setup best. Thanks for your understanding.

I understand. I do know basic debugging and have it all set up on my system, but a starting point/where to look for would be useful. I'm not so much into the TYPO3 core.

Ups, I understood you wrong. ;-)
Sure I can give you a hint about breakpoints.

Start with:
typo3/sysext/install/Classes/Updates/AbstractDatabaseSchemaUpdate.php line 68 ($this->schemaMigrationService->getFieldDefinitions_database();)
Step into the getFieldDefinitions_database() function and have a look what is going on in there. I guess line 197 is the most interesting part, where a table's fields are loaded.

I found that the main reason for this are differences in the file ext_tables.sql and the return of MySQL.
Under TYPO3 6.1 in file /typo3/sysext/install/Classes/Updates/SchemaMigrator.php - function getDatabaseExtra around Line 344:
You can check a given table with this:

    public function getDatabaseExtra($FDsrc, $FDcomp, $onlyTableList = '', $ignoreNotNullWhenComparing = TRUE) {
        $extraArr = array();
        $diffArr = array();
        if (is_array($FDsrc)) {
            foreach ($FDsrc as $table => $info) {
// added lines
                if ($table == 'tx_toctoc_comments_ipbl_static') {
                    print '<br>file:<br>';
                    print_r ($FDsrc[$table]);
                    print '<br>database:<br>';
                    print_r ($FDcomp[$table]);
                    exit;
                }
// end added lines
                if (!strlen($onlyTableList) || \TYPO3\CMS\Core\Utility\GeneralUtility::inList($onlyTableList, $table)) {
                    if (!isset($FDcomp[$table])) {
...

replace 'tx_toctoc_comments_ipbl_static' by the table you want to see the two arrays (from file versus from MySQL).
Then run Compare Database in Installtool to see the output.
I found often spaces in the ext_tables.sql to be the cause of the "DROP KEY - ADD KEY"-Bug. But Comparing the 2 arrays shows all possible causes.

What are the differences you saw?