Re^2: DBI/MySQL/MariaDB clone tables across DB Connections

Thanks, I look into it. :)

execute_for_fetch and execute_array were new to me...

> I would go the route of dumping things to files and then importing from files

It's a multi-user web application were users are copying (relatively small amount) of config data across servers.

Those are "transported" in temp tables which can be easily checked and reproduced.

So I'd rather avoid managing temp files per user on the web-server...

Cheers Rolf
_{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)

Wikisyntax for the Monastery}

Comment on Re^2: DBI/MySQL/MariaDB clone tables across DB Connections Select or Download Code

Replies are listed 'Best First'.

Re^3: DBI/MySQL/MariaDB clone tables across DB Connections
by Bod (Parson) on Apr 06, 2023 at 21:37 UTC

I would go the route of dumping things to files and then importing from files

This is the way I would usually go...but...
be aware that it is a great pain if you are using MariaDB System Versioned tables.

mysqldump will dump the current data but not the historic data and recreating the historic data is a pain as I have found to my cost.

I made a bad design decision to use 'email' as a primary key on a database where users can have multiple email addresses stored. I don't know what possessed me not to use a system-generated key but I did. I only realised once there was data in the data - both current and historic. I could not find a way to add a field with AUTO_INCREMENT so I ended up copying the current data to a new table, dropping the offending table, rebuilding it with a generated primary key and then reimporting the data to the table. But, being system versioned, I lost all the historic data.

This wasn't the end of the world as it was all test data. Recently, the production database has been built but not before carefully checking every table for similar traps. I found one - using phone numbers as a primary key!

It should be possible to restore historical data to system versioned tables by setting the @@timestamp variable but I've not tried it yet. Once I have the production system up and working (launch date is next Monday), I will test writing a backup and restore utility that plays with @@timestamp to properly restore system versioned tables.

[reply]
[d/l]
[select]


Problems? Is your data what you think it is?
	PerlMonks