Ticket #715 (closed Task: fixed)

Opened 1 year ago

Last modified 3 months ago

Keeping track of applied database updates

Reported by: Eric Myers Assigned to: davea
Priority: Undetermined Milestone: Undetermined
Component: Server - Other Version:
Keywords: database update Cc:

Description

I suspect many projects don't upgrade because it is not easy to do, and one thing that takes time and attention is doing the database updates. You have to sort out by hand which ones you've already applied and only apply the new ones. It would be very useful if a log was kept of which updates had been applied. Even better, when running the update script have it check this log and decline to apply the updates which have already been applied.

The attached file, db_update_util.php, contains a modified version of the do_query() function which does all that. It can handle updates which consist of more than one mySQL request. The log file db_update.log is kept in the project log directory, and while the lines written to it by do_query() have a timestamp, one can also add lines by hand with just the names of previously applied updates.

Attachments

db_update_util.php (4.1 kB) - added by Eric Myers on 08/06/08 16:17:03.
Modified do_query() to keep a log of applied database updates.

Change History

08/06/08 16:17:03 changed by Eric Myers

  • attachment db_update_util.php added.

Modified do_query() to keep a log of applied database updates.

08/06/08 16:39:14 changed by Nicolas

  • type changed from Enhancement to Task.

(follow-up: ↓ 4 ) 08/06/08 16:55:27 changed by davea

  • status changed from new to closed.
  • resolution set to wontfix.

This seems like a lot of code for little gain; It's easy to see if an update has been applied (e.g., "explain app" in mysql) and it's a no-op if you try to apply an update twice.

What I'd rather see is for "upgrade" to do the needed updates automatically (after a y/n confirmation)

08/06/08 17:14:23 changed by Nicolas

  • status changed from closed to reopened.
  • resolution deleted.

#597, #600, and #602 also look like a lot of code for little gain (compared to other more important tasks). That's why they were marked as "complex" in DevProjects.

To have "upgrade" do the needed updates automatically, you need to keep track of them so this isn't useless.

Keeping track of database updates is important. Maybe Eric's script isn't the best to do it. Tickets don't necessarily need to be closed with the suggested fix.

(in reply to: ↑ 2 ) 08/07/08 08:14:06 changed by Eric Myers

Replying to davea:

This seems like a lot of code for little gain;

It is lot of code, but not all that much. That point is irrelevant. It was very useful for me, and hopefully will be to others. The polite and correct response is "Thank You". Or "no thank you".

It's easy to see if an update has been applied (e.g., "explain app" in mysql)

But that is manual. You have to do that for each one. Many people running projects just won't bother. This makes it easier.

and it's a no-op if you try to apply an update twice.

Maybe. Depends on what the update does. And when you run an update twice you do get error messages that can make it seem there is a problem. Just run it once.

What I'd rather see is for "upgrade" to do the needed updates automatically (after a y/n confirmation)

Then I'll add that next to the upgrade script, which I've also just been working on. Dead easy, given this bit.

(follow-ups: ↓ 6 ↓ 7 ↓ 8 ) 08/07/08 08:30:07 changed by davea

Um, the correct way to contribute code to BOINC is to propose and discuss the design (with me and boinc_dev) first, program second.

(in reply to: ↑ 5 ) 08/07/08 10:09:01 changed by Eric Myers

Replying to davea:

Um, the correct way to contribute code to BOINC is to propose and discuss the design (with me and boinc_dev) first, program second.

Sorry, I did not mean to be snippy. I'm just frustrated you don't see the utility of my idea. I realize I need to convince you. I will. :-)

I'm trying to find the right way to contribute things. I recently sent you and Rom some notes on small problems I found and got no response, so it seems those are more appropriate for tickets. I will file them. I coded this enhancement because I really wanted it (otherwise I'd never update my project) and thought I'd share it. I thought I'd file that as a ticket too. I guess that was wrong.

There are so many different channels of communication available that it's not always clear which one is the correct one for the particular message. Sorry.

(in reply to: ↑ 5 ) 08/07/08 14:39:54 changed by Nicolas

Replying to davea:

Um, the correct way to contribute code to BOINC is to propose and discuss the design (with me and boinc_dev) first, program second.

When have official devs done that? I've yet to see the design proposal of the multithreaded GUI RPCs.

(in reply to: ↑ 5 ) 08/07/08 15:04:36 changed by Didactylos

Replying to davea:

Um, the correct way to contribute code to BOINC is to propose and discuss the design (with me and boinc_dev) first, program second.

Tried that. Wasted a year of my life. Thanks for that!

The process has to go both ways, or it doesn't work.

10/04/08 13:27:42 changed by Nicolas

Related (duplicate?): #745.

03/10/09 16:32:25 changed by Nicolas

  • keywords changed from database update to database update from-devprojects.

03/10/09 16:33:10 changed by Nicolas

  • keywords changed from database update from-devprojects to database update.

oops

05/29/09 16:44:24 changed by davea

  • status changed from reopened to closed.
  • resolution set to fixed.

This is implemented by html/ops/db_update.php

If this page is incomplete or incorrect, please edit it or add it to the wiki to-do list. To do this, you must be logged in; click Login or Register above.