This is basically for Rod. I noted during testing of Bill’s script that the restore script creates the mysql default database encoding (in most cases this will be latin1). This will begin to be an issue, because as tables are added during upgrades, users that have pure UTF-8 databases(3.1.0+) will begin to have hybrid databases(3.0.0 all over again…). Couldn’t think of an obvious way to solve this dilemma:
1) Perhaps can search the openemr.sql and if all tables are default collate=utf8 then could instead create a utf-8 database.
Can’t find any mysqladmin paramteres to set the default-collate. That is annoying. May just need to create the database with the mysql command instead with create command:
Agree we need to ask during restore. Looking ahead, could also make seamless(rather easy to do this) for newer users by placing a small meta file during backup that contains the default character set and collation of the database in the small meta file. Then if this file exist during restore could use this instead. This will avoid the multitude of errors possible if users get the chance to select (agree a selection is needed though to be compatible with the older “backup packages” that won’t contain a meta file.)
Agreed. But for now I’ll just do some simple update to the restore script. Longer term, probably a better solution is a stand-alone web script for restoring, something that also works with Windows.
A web restore script would be doable, if a bit strange since it wouldn’t be able to run in the OpenEMR context by definition… but could just be a php script the kind-of looks like it belongs to OpenEMR by using the configured theme. Be kind of tricky to get that without loading all of globals.php … which, of course, brings up the concept of a modular globals file. …. and a new thread.
It could just be a stand-alone script like sql_update.php that does what the contrib/util/restore script does (run through this script to get an idea; it’s very cool; gives options to change path/sql-user/sql-database or keep originals). The obstacle that may be difficult to overcome are the file/folder permissions, since script would be run as the webserver user. A php CLI script would actually solve this dilemma. So perhaps simply converting the contrib/util/restore script to a php CLI script would make it cross-platform (note it appears xampp supports php CLI scripts).
What would be the advantage of a PHP CLI script over the current shell script?
I think a PHP web script is do-able. It would just need a directory writeable by the webserver user as a prerequisite… not too unreasonable since someone also has to put the script itself on the server. Maybe package the whole thing up as a .deb or whatever. Advantage is it can present a nice GUI for the restore options.
After more thought also agree that a web script with a GUI is better; could just instruct user to make the directory and even check directory permission before proceeding (like in initial screen of installation).
I lean toward the web based one, but the advantage of PHP CLI is that it’s cross platform, shell is only available if you installed GNUTools support for windows. The fewer differences between code on the platforms the easier it is to maintain and enhance down the road.