Bug 248175 (bz-dbinstall)

Installation needs to support DB-independence

RESOLVED FIXED in Bugzilla 2.20

Status

()

enhancement
P1
normal
RESOLVED FIXED
15 years ago
5 years ago

People

(Reporter: bugreport, Assigned: mkanat)

Tracking

(Blocks 1 bug)

2.17.7
Bugzilla 2.20
Dependency tree / graph
Bug Flags:
blocking2.20 +

Details

Reporter

Description

15 years ago
Today, checksetup makes mysql assumptions all over the place.  For 2.18 and
prior, that is a safe assumption.  BEFORE anyone lands a DB-compatibility
solution, we need to fix this.

My suggestion is as follows....

First, move the code that upgrades sites from checksetup to legacychecksetup,
deleting the module checks and the administrator setup in the process.

The new checksetup should perform operations in the following order...
1) Check requirements
2) Determine current Table configuration (schema only)
  [If current predates new checksetup, call the old checksetup code]
3) Add new fields/tables to schema (or ask a DBA to do so)
4) Determine migrations to be done [cannot rely on information from step 2, we
may be run again after a DBA finishes the schema adds]
5) Do the migrations
6) Determine the schema deletions or renames to be done

I am suggesting we make a point of preserving the old upgrade code prior to the
first version that does this.  The whole approach still does raise some
interesting questions. Such as...

a) If extra fields or tables are in the DB and not in checksetup, do we
automatically remove them or do we keep a list of fields that checksetup has
ever wanted to remove.
b) Can we always determine what conversion code needs to run solely by looking
at the schema?

For example, we add a new field that never existed...
-->We should be able to just add it to the db-independent table description.

add a new field that needs program initialization
-->We add it to the db-independent table description.
-->init code checks for the field existing AND being uninitialized

change a field to a reference to another table
-->We add the new stuff to the db-independent table descriptions.
-->init code checks for the new field existing AND old field existing AND being
uninitialized
-->cleanup code checks for the new field existing AND old field existing AND
initilization already done --> deletes old field

etc...
Reporter

Updated

15 years ago
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.20
There's nothing wrong with automatically performing schema updates and data
conversions at the same time...  however, it all needs to happen from a separate
script that can be run by the DBA.

In the typical enterprise world, the application user ('bugs') is not going to
be granted enough permissions to create, alter, and drop tables.  The primary
checksetup.pl script, run by the application admin, should be able to tell if
changes are necessary, but not actually make them (of course, it can offer to
run the upgrade script, so it can all be done at once if needed).  The script
which actually makes the changes should prompt for a DBA username and password,
rather than using one from a data file.

The checking can always be done from the same script, and called in such a way
that it knows to log in with the normal bugs user and only check instead of
update, so we avoid duplication of code.

Ideally, to prevent stranding people using a specific database, there should NOT
be a separate upgrade/setup script for each database, but instead try to do it
in a database agnostic way as much as possible, and use some kind of common
schema definition that defines any extra attributes needed for tables/columns to
deal with the places where being agnostic isn't possible. (which is what bug
146679 is about I think)
Depends on: bz-dbschema

Comment 2

15 years ago
(In reply to comment #1)
> Ideally, to prevent stranding people using a specific database, there should NOT
> be a separate upgrade/setup script for each database, but instead try to do it
> in a database agnostic way as much as possible, and use some kind of common
> schema definition that defines any extra attributes needed for tables/columns to
> deal with the places where being agnostic isn't possible. (which is what bug
> 146679 is about I think)

Certainly. I've always hoped that a future version of checksetup.pl would utilize the Schema modules 
that I and others have been working on in bug 146679, but I'm hoping someone else will take care of 
adapting checksetup.pl to utilize the Schema modules. Right now, the Schema object class only has a 
single public method (besides the constructor) that returns all of the SQL used to create the Bugzilla 
schema. Can anyone think of any other methods that checksetup.pl might need from the Schema class?
Reporter

Comment 3

15 years ago
Here's the point...

The existing (legacy) checksetup will have to get mysql legacy (the only kind
that exists) up to some key point.  Starting with that point, whatever does this
must carry all the schema forward in an agnostic way.

I think we are all saying the same thing. However, it is easy to forget that
this needs more than just a way forward alone.  The checksetup replacement must
know when it has to call the legacy checksetup for upgrading sites.
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Assignee

Comment 5

15 years ago
I'll take this, because it's one of two major blockers for bug 98304, which is
important to me.

I think what's really important is that checksetup needs to support
DB-independence. It doesn't have to be *replaced* in order to do this, it just
has to do it. We have years and years of stable code in checksetup, there's no
need to throw it all away just because it's large and complicated.

If we'd like to re-write checksetup for some other reason, I think that could be
another bug.

If anybody disagrees, and would actually like to write this code, they can feel
free to take this bug back from me. :-)
Assignee: zach → mkanat
Summary: Checksetup needs to be replaced to support DB-independence → Checksetup needs to support DB-independence
Assignee

Updated

15 years ago
Depends on: bz-enums
Summary: Checksetup needs to support DB-independence → Installation needs to support DB-independence
Assignee

Updated

15 years ago
Depends on: 277617
Assignee

Comment 6

15 years ago
I'm going to start working on this on what will essentially be a large fork
(with the current patches in bug 146679 and bug 277617) and then merge some of
my changes back in.
Status: NEW → ASSIGNED
Target Milestone: Bugzilla 2.22 → Bugzilla 2.20
Assignee

Updated

15 years ago
Alias: bz-dbinstall
Assignee

Updated

15 years ago
Depends on: 284172
Assignee

Updated

15 years ago
Depends on: 284348
Assignee

Updated

15 years ago
Depends on: 284525
Assignee

Updated

15 years ago
Depends on: 284529
Assignee

Updated

15 years ago
Depends on: 284845
Assignee

Updated

15 years ago
Depends on: 284850
Assignee

Updated

15 years ago
Depends on: 285111
Assignee

Updated

15 years ago
Depends on: 285119
Assignee

Updated

15 years ago
Depends on: 280856
Assignee

Updated

15 years ago
Depends on: 285121
Assignee

Updated

15 years ago
Depends on: 285443
Assignee

Updated

15 years ago
No longer depends on: 285443
Assignee

Updated

15 years ago
Depends on: 285551
Assignee

Comment 7

15 years ago
This and all its deps is currently the major 2.20 blocker.
Flags: blocking2.20?
Flags: blocking2.20? → blocking2.20+
Assignee

Updated

15 years ago
Depends on: 286669
Assignee

Updated

15 years ago
Depends on: 286672
Assignee

Updated

14 years ago
Depends on: 289139
Assignee

Updated

14 years ago
Depends on: 289453
Assignee

Updated

14 years ago
Depends on: 289455
"If it's not a regression from 2.18 and it's not a critical problem with
something that's already landed, let's push it off." - Dave
Flags: blocking2.20+
Flags: blocking2.20-
Flags: blocking2.20-
Assignee

Comment 9

14 years ago
Without this bug landing, no PostgreSQL installation will be able to upgrade to
2.20. So I'd say it blocks 2.20.
Flags: blocking2.20?
Assignee

Updated

14 years ago
Priority: P2 → P1
Flags: blocking2.20? → blocking2.20+
Assignee

Comment 10

14 years ago
OK, this bug is now considered complete now that all blockers have been
resolved. From now on, the ability to install on a new DB should depend mostly
on just writing a new driver and the associated Schema module.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.