If you try to remove a Koha instance that is using a remote database, it will fail and the sysadmin will feel sad. We already provide a mechanism by which we don't touch the mysql bits (--keep-mysql), it might be nice to explain in the help that using this will allow a sysadmin to remove the front-end of Koha and remove the remote database independently, at a later (or previous) time. I don't think we need a different option, maybe the existing one needs a different name... I'm not really sure.
the only option name that is coming to my mind on this sunny friday afternoon is "--no-touchy-the-database-bits" I don't think that would really be good. :)
Created attachment 44347 [details] [review] Bug 15088 - notice when koha has been installed with --request-db instead of --create-db Patch does 2 major things - * creates an options file during koha-create that lets us know what database option was used when the instance was created /etc/koha/sites/$name/createoptions * when an instance is removed, we assume we can do things to the database, per usual. If we have a createoptions, we'll read it and find out if our instance was created with create-db or request-db. If it was requested, we don't do anything with the database because we assume we don't have rights to, and print a message. If it was created, we do the same thing we've always done - remove the database and users (unless we've specified --keep-mysql) To test: create a throwaway instance with --create-db remove that instance, all should happen as normal. your instance should have an /etc/koha/sites/$name/createoptions file with REQUEST_DB=0 in it. create another throwaway instance with --request-db remove that instance, you should see a message alerting you to the fact that you may still have database work to do after Koha is removed. your instance should have an /etc/koha/sites/$name/createoptions file with REQUEST_DB=1 in it.
(I had a bit of a change of heart on how to handle this, after consulting with the most excellent Robin.)
"Koha instance is empty, no staff user created." -- Oops. In a fresh install without a pre-existing DB, this doesn't work.
I don't understand, that behaviour predates this patch. Liz
(In reply to Liz Rea from comment #5) > I don't understand, that behaviour predates this patch. > > Liz That's not the issue. Read the code. I called a fresh install with create DB and the createoptions file was empty, because it generated the else case. That's the else case message. That's why I put it to Failed QA, because it doesn't notice when it was called with --create-db in the case of a fresh install.
Created attachment 48184 [details] [review] Bug 15088 - Follow for koha-create Logic in the koha-create was requiring a DEFAULTSQL to trigger. This patch moves it, such that --create-db will be registered all the time.
Created attachment 48186 [details] [review] [SIGNED-OFF] Bug 15088 - notice when koha has been installed with --request-db instead of --create-db Patch does 2 major things - * creates an options file during koha-create that lets us know what database option was used when the instance was created /etc/koha/sites/$name/createoptions * when an instance is removed, we assume we can do things to the database, per usual. If we have a createoptions, we'll read it and find out if our instance was created with create-db or request-db. If it was requested, we don't do anything with the database because we assume we don't have rights to, and print a message. If it was created, we do the same thing we've always done - remove the database and users (unless we've specified --keep-mysql) To test: create a throwaway instance with --create-db remove that instance, all should happen as normal. your instance should have an /etc/koha/sites/$name/createoptions file with REQUEST_DB=0 in it. create another throwaway instance with --request-db remove that instance, you should see a message alerting you to the fact that you may still have database work to do after Koha is removed. your instance should have an /etc/koha/sites/$name/createoptions file with REQUEST_DB=1 in it. NOTE: Only works in conjuction with my patch. Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Created attachment 48187 [details] [review] Bug 15088 - Follow for koha-create Logic in the koha-create was requiring a DEFAULTSQL to trigger. This patch moves it, such that --create-db will be registered all the time.
If you could test and sign off, Liz, I would be glad to have this set to signed off.
Created attachment 52004 [details] [review] Bug 15088 - Follow for koha-create Logic in the koha-create was requiring a DEFAULTSQL to trigger. This patch moves it, such that --create-db will be registered all the time. Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Just to make sure: We are creating a new options and a new file, just to display an alert? Why not try to drop it and display the alert if the DB has not been deleted?
Hi, Yes, that is what we're doing. When you put it that way, it seems crazy. However, crazy as it sounds, my thinking was that there might eventually be other things that we wanted to keep track of in a centralised location. I see it as the first instance of having a method of making a Koha self-documenting. A way to make sure we can know how a koha was originally installed, a way to ease troubleshooting for admins, a way to provide explicit error messages for specific types of installations. As Koha installations pass from admin to admin, knowledge is lost. When the knowledge is lost, libraries leave Koha. This desire of mine may not be enough to encourage acceptance of this patch. That's fine. I just wanted to make sure you knew where my head and heart were at when I submitted this in this way. Liz
Ccing Tomas to get his opinion.
(In reply to Jonathan Druart from comment #14) > Ccing Tomas to get his opinion. *pong*