As far as I remember phpMyAdmin is a php script that can be downloaded from a website and installed on any host just like SMF (well, mostly).
A number of people have complained that they do not have phpMyAdmin (or a similar utility) on their systems. If their hosts are unwilling to install phpMyAdmin, what chance do they have to install it themselves? Just saying...
The conventions are pretty straightforward: the standard SQL method to escape single quotes is a double single-quote.
MySQL extends the standard and allows both the double single-quote and the slash+single quote (where the preferred is probably the \', but that's just a guess).
That is why I find very strange this problem, because AFAIK is MySQL itself the only tool that uses this kind of escape.
I guess we need to decide what kind of cross-database/cross-utility capability is needed for our backups. Conceivably, a backup made on MySQL
could end up being restored on PostgreSQL, etc. If there's any mode which is universally acceptable, let's use it. Otherwise, we'll need to be able to import/export "foreign" formats.
While we're at it, an SMF backup utility should offer ways to break up both the backup and the restore into smaller pieces, so jobs aren't killed due to timeouts.
If you mind to test the dev-snapshots you would notice the timeouts don't happen any more.
Is everyone satisfied that timeouts won't happen on
any host? Not just the one or two you tested your changes on. It's now impossible to get a timeout on either backup or restore on any "reasonable" host? Even if the database is absolutely humungous? Even if a standard utility like phpMyAdmin is used instead of SMF's backup/restore?
Additionally how I already explained split would be useless for several reasons:
1) you need to store the database on the publicly accessible space of the host (a writable directory that most likely would be in the vast majority of the cases cache or in the most lucky attachments),
I don't get it. What's any different about writing multiple .sql files with different names, than a single .sql file? You've got to write it
somewhere.
2) breaking the database would take much more time to actually complete the backup, that would mean the users shall put the forum in maintenance otherwise the backup will lack of consistency,
Well, yes, writing multiple files probably
will take a bit longer than writing a single file, but not "much more". A forum should
always be in maintenance mode during a backup or restore, and it should be done automatically (or, refuse to run unless the user has already put it in maintenance mode). Otherwise you end up with inconsistencies.
3) the code to break things up needs to be more complex,
Say, every 1000 records (or some other user-configurable value) increment a file counter and start a new output file. The last file could have some sort of marker in a comment so that the SMF restore utility knows it's the end. It's doesn't seem to be much more complex to me.
4) you will have to explain to the users that they have to strictly follow the order to re-upload the files, otherwise the consistency would go to...
The consistency would go to vB?
Put all the table DROPs and CREATEs in the first backup file, and then after that it doesn't matter what order they're done in. With numbered backup files, you could automatically import them in sequence in a restore utility. Using phpMyAdmin, the user would have to watch the sequence numbers to make sure they do "1" first. After that, it doesn't matter.
I'm not sure we're talking about the same thing when we say "split the backup". What I'm meaning is "back up the database into multiple, relatively small .sql files so that neither the backup nor restore (nor the file transfers) time out. This
may involve playing some games so that a fresh process is started for the next .sql file -- maybe holding the last .sql file number done, and (for backup) its table and its ending record number in a scratch file or something. That might be necessary to avoid a timeout. Start with some large number of records to process per file, and if the user experiences timeouts they can adjust this record count down to where the backup and restore processes manage to run OK. Feasible?
Convert from a backup is pretty difficult/annoying.
Additionally many conversions don't make much sense: basically any conversion to SQLite is pretty much useless, and I don't think there are many people that would switch from MySQL to Postgres or vice versa...
Also SQLite to Postgres is unlikely...I'd guess.
As mentioned before, if there's a universal format we should use that. Otherwise, foreign format import/export for SMF's utility should be supported, and we can think about converting between .sql file formats if necessary. After all, sooner or later someone is going to decide they want to move to another host that doesn't support, say, MySQL, and all they have is a MySQL backup. SMF looks much better if we can say, "No Problem!"
