Re: Managing database change: improvements needed

["R. Ransbottom" <..hidden..>]

On Sun, Sep 13, 2015 at 12:20:49PM +0200, Erik Huelsmann wrote:
> On Sat, Sep 12, 2015 at 4:27 PM, R. Ransbottom <..hidden..> wrote:


> > I'd try to write a script with good error catching.

> It's not impossible, but a *lot* more work than tracking which changes have


> 1) Number/name the scripts and keep a catalog of the names/numbers, which
> can be queried by the update program
> 2) Query PostgreSQL's own schema catalog for specific characteristics and
> conditionally execute the DDL change commands

> (2) would AFAIK require coding a specific stored procedure for each change,
> while (1) is exactly the direction I'm proposing (by using Sqitch to do it
> for us, that is).

This ignores the fact that the current scripts work.  The need is just to 
silence the noise!  

The disadvantages of sqitching are: (1) splitting up the code clients or
developers may want to review, (2) fixing an unbroken process (time 
poorly spent), (3) verification of verification scripts (logic errors 
and collisions) (4) another dependency, (5) reliability, and  
(6) dealing with user changes made by those who ignored sqitch 
as "only another dependency".

Sqitch reliability sounds good where there is one deployer; where 
deployers duplicate deployments it is not so well valued.
 
> changes and (y') is the schema for the new version, including your changes

> (as long as there are no conflicts, of course).

Which is the modded users' unique concern.  

A namespace reservation could ease that issue.

> This way, you get the benefit of re-using the efforts from the project and
> a full re-analysis of the schema wouldn't be necessary.

This seems like a red herring.  A full re-analysis never came 
into consideration.  

Are you overly enthused by what you believe sqitch will accomplish
for lsmb?  

I see the conversations about 1.5 and big changes that Chris and you 
would like to make.  Those tell me that this is not a time for 
new toyism and feature creep, but a time for formalizing code and design, 
for making the code freezable, for finding code creating tools that will 
improve production, and maybe having the "big" rewrite.  In this train, 
sqitch is just an ill timed distraction.

> > > One reason why I like the way Sqitch works is that you'll be able to put
> > > your schema changes in sqitch files and deploy those on your LedgerSMB

It does sound great in the ads.


> No :-) But Sqitch does a number of things we currently don't do:

> 1) Check deployment consistency before deployment of new changes

What happens if my 1.4.9 is not consistent, how do I move forward?
Learn sqitch, I suppose.

> 2) Allow verification of the deployment afterwards

Somehow this has been done. 

> 3) Prevent duplicate application of changes,
>      --> making the deployment logs clean of errors
>           --> no longer frightening users who take a peek in this log

Suppress the noise--one task.

> 4) Provide a downgrade path

You already are renaming the schema thereby providing a down path 
with less complexity.


>                     I'm looking at it from the perspective of
> the software that the LedgerSMB project distributes. This means thousands
> of databases across the world in way more than 2 data centers (sometimes

But it is not your task to redeploy them.  97% of those probably have
one company running and would likely prefer not to be bothered. Those
that have multiple companies would probably like to syncronise (modulo
a test case) upgrades; again a simpler case.  No one wants to downgrade
past where they were.

The beauty of the sqitch idea, is to organize the code, so moving amongst
many different versions is easy.  In the lsmb case, that supports a 
dis-incentive for users to upgrade.

> just at home), completely out of the control of the project, where
> deployments should "simply work", upgrading from anywhere from 1.2.<latest>
> or SQL Ledger 2.6/2.8 to the version being upgraded to.

I been lurking around for over two years and I've seen few 
how-do-I-get-from-A-to-B questions.

> I'd like the switch to Sqitch to help people with local schema
> modifications to maintain their modified database and enjoy the regular

As a customizing user: sqitch doesn't address my issue at all; if I install
a VCS, sqitch doesn't do much for me.

> Please note that I'm very much valueing your feedback,

I am American, we are reknown for rudeness and insensitivity; I try
to break that mold.  I don't have a problem with you thinking I'm wrong;
I hope to be at least as gentle as you.

Rob

------------------------------------------------------------------------------
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel