I'm trying to migrate from a Drupal 8.x using the MSSQL database to the Drupal 8.x MYSQL database. I tried to migrate using Mysql workbench(Schema and data).
Looking in the code of the sqlsrv module, I noticed there are few technical columns used for the computed keys or technical primary key(start with "__"). As Mysql driver won't require these additional columns, I tried simply deleting these columns and then performed the Mysql database migration wizard. The database migration wizard works but, when I looked at the tables there were few tables(__pk tables) where the schema was not migrated fully. I mean table schema was not matching comparing with a table schema in another Mysql DB(created using Drupal install). Is this the correct approach? Is there any script available through which I can do the migration. Does removing these "__" pk columns are enough or there is something more to do? Please help.
Comments
Comment #2
beakerboyThe sqlsrv driver adds columns to tables in a few situations. One, if a user creates a table and does not include a primary key in the schema, the driver makes the decision to add one. I’m guessing this is to make queries against this table more efficient. In the second case is if the user DOES specify primary keys, but the clustered index is larger than some value.
I would guess that you could delete these columns, but you would have to determine if other columns need to then be designated as primary keys.
Comment #3
avpadernoComment #4
beakerboyA potential solution to your problem would be to use drupal as the migration tool. You can set up multiple database definitions in your site settings. You may be able to query the nodes and entities from the old site and use drupal to insert them into the new database. This way you do not need to know anything about the database schema.
I’m in the process of doing this right now. I have a site that is using a custom CMS and PostgreSQL, and using a custom module to query the old database, reformat the data into what is needed for my Drupal entities, and saving each entity.
Comment #5
beakerboyThe technical columns are there for a reason, and the names are well defined. If someone want to migrate data, they can use the migrate module, or code their own and avoid pulling these data if they don’t want it.