Schema drift detection seems incorrect about bytebase HOT 7 CLOSED

I will take a look. Thanks for reporting.

from bytebase.

Hi linucksrox@, we need a bit more information to understand your setup and find the cause. Schema drift anomaly detects one-off manual schema changes that are not done by Bytebase. It will get the database schema [1] and compare it with the latest record in bytebase. In the scanner, we don't check gitlab latest file because that's expected to be the same in the migration history record. Would you help take a look at your migration history records in your MySQL instance?

For 2), do you mean AUTO_INCREMENT shouldn't be part of the schema or something else? If you mean the data values associated with an AUTO_INCREMENT column, that's not part of schema.

Thanks!

[1]
https://github.com/bytebase/bytebase/blob/main/server/anomaly_scanner.go#L296
[2]
https://github.com/bytebase/bytebase/blob/main/server/anomaly_scanner.go#L313

SELECT * FROM bytebase.migration_history WHERE namespace="git123" ORDER BY created_ts DESC LIMIT 1;

from bytebase.

@spinningbot thanks for the info. I'm starting fresh with Bytebase 0.9.0 and just did a baseline migration from my current schema. It just ran and is behaving the same way. I did not make any schema or data changes since the base migration, but once the anomaly scanner ran it is detecting that several tables and views are changed. Now that I look more closely at the migration history, that doesn't include the full schema either. It appears to be truncated, and I wonder if there is a character limit. I have 82 tables and several views/procedures as well. Is there a character limit for the migration history?

In my case there are 66,947 characters in the truncated version, but the actual full length is 80,000 characters.

Regarding AUTO_INCREMENT, I don't mean the data values associated with that. What I mean is the default AUTO_INCREMENT value. For example, from the base migration I see a CREATE TABLE statement that looks like this:

CREATE TABLE `contract` (
  `contract_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `revision` int(10) unsigned NOT NULL,
  `start_date` date DEFAULT NULL,
  `end_date` date DEFAULT NULL,
  PRIMARY KEY (`contract_id`),
  UNIQUE KEY `contract_index2965` (`contract_id`,`revision`)
) ENGINE=InnoDB AUTO_INCREMENT=2345 DEFAULT CHARSET=utf8;

Later, after more records are inserted into the contract table, the AUTO_INCREMENT schema value changes. So if I added 4 records to the table, then the anomaly scanner runs, it detects that the schema changed because it's expecting AUTO_INCREMENT = 2345 but in the actual schema is now AUTO_INCREMENT = 2349. I wonder if this should be excluded from the schema anomaly checker.

from bytebase.

For AUTO_INCREMENT, we consider the starting value to be part of the schema if and only if when data is dumped together with schema so that the restored database is an exact clone of the dump. Otherwise, the starting value isn't part of the schema if we dump schema only. Will work on a change.

from bytebase.

Closing the bug. @linucksrox plz let us know if this fixes the issue when our next release goes out (ETA late next week) or if you wanna try out HEAD version. Thanks!

from bytebase.

@spinningbot Thanks for the fixes. I manually changed from TEXT to MEDIUMTEXT in the bytebase table and tested from the main branch and this is working perfectly for me now.

from bytebase.

@spinningbot Thanks for the fixes. I manually changed from TEXT to MEDIUMTEXT in the bytebase table and tested from the main branch and this is working perfectly for me now.

Awesome, thanks!

from bytebase.