You could use the execute_for_fetch method of DBI but I would go the route of dumping things to files and then importing from files, since that allows better granularity in the sense that either a table is imported completely or not at all.

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}

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.

For the records:

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

I just had to go the execute_for_fetch route for yet another project, and it's surprisingly fast, thanks for that! :)

But ...

> since that allows better granularity in the sense that either a table is imported completely or not at all.

When dealing with MySQL or MariaDB this depends on the engine used, since I get an array of potential errors returned from execute_for_fetch ...

On InnoDB I can then decide to either ->commit or ->rollback and this works fine.

But on MyISAM transactions and rollbacks are not supported.

There I have to go the route of using intermediate temporary tables to be safe(r).

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

But on MyISAM transactions and rollbacks are not supported

They are also quite old and can be unstable. I never did find out why but I had some intermittent data loss from MyISAM so I am now using Aria tables instead, or InnoDB if I really need to enforce referrential integrity (which is rare).

The only downside I have found with the Aria storage engine is that MySQL Workbench doesn't recognise them so can't generate forward engineered code. But that has the positive of improving my DDL familiarity which had got very rusty!

  my $txn= $db2->txn_scope_guard;
  $db2->resultset($table)->populate([
    $db1->resultset($table)->hri->all
  ]);
  $txn->commit;
[download]