In response to Roger Leigh :
> On Thu, Feb 10, 2011 at 02:58:15PM -0700, Rob Sargent wrote:
> > On 02/10/2011 02:38 PM, Royce Ausburn wrote:
> > > My company is having trouble managing how we upgrade schema changes across
> > > many versions of our software. I imagine this is a common problem and
On Thu, Feb 10, 2011 at 02:58:15PM -0700, Rob Sargent wrote:
> On 02/10/2011 02:38 PM, Royce Ausburn wrote:
> > My company is having trouble managing how we upgrade schema changes across
> > many versions of our software. I imagine this is a common problem and
> > there're probably some neat solut
On Fri, 2011-02-11 at 08:35 -0500, Daniel Popowich wrote:
> think no software process can make anyone happy. It's a human
> process: declare someone the owner of the database schema, let them
> own the long term development of the schema, and if anyone needs a
> change, they have to communicat
> What about upgrades that can't be derived directly from an inspection
> of the schema? Some examples:
>
> - Adding a NOT NULL constraint (without adding a DEFAULT). You often
> want to precede this with filling in any existing NULL values, so the
> new constraint doesn't fail.
This is an imp
On Fri, Feb 11, 2011 at 8:35 AM, Daniel Popowich
wrote:
> FWIW, this is what I do:
>
> 1. I have a table in my database, meta, that contains exactly one
> row, and holds configuration information. A minimal version of this
> table:
>
>CREATE TABLE meta (
>id integer DEFAULT 1 NOT
In response to Alban Hertroys :
> On 10 Feb 2011, at 23:59, Bill Moran wrote:
>
> > The overview:
> > You store your schema and data as XML (this is easy to migrate to, because
> > it includes a tool that makes the XML from a live database)
> > Keep your XML schema files in some RCS.
>
> That re
Glenn Maynard writes:
> - Adding a NOT NULL constraint (without adding a DEFAULT). You often want
> to precede this with filling in any existing NULL values, so the new
> constraint doesn't fail.
> - Updating triggers, functions and their effects. For example, when I have
> an FTS index with a t
In response to Andre Lopes :
> Hi,
>
> Where can we donwload dbsteward?
You can't yet. We're still in the process of getting everything lined up
to release it.
We've registerd dbsteward.org, so when we have things ready, that'll be
where you can go. Expect it to come live in the next few mont
Hi,
Where can we donwload dbsteward?
Best Regards,
On Fri, Feb 11, 2011 at 5:16 AM, Bill Moran wrote:
> In response to Glenn Maynard :
>
>> On Thu, Feb 10, 2011 at 6:44 PM, Bill Moran wrote:
>>
>> > dbsteward can do downgrades ... you just feed it the old schema and
>> > the new schema in rev
On 10 Feb 2011, at 23:59, Bill Moran wrote:
> The overview:
> You store your schema and data as XML (this is easy to migrate to, because
> it includes a tool that makes the XML from a live database)
> Keep your XML schema files in some RCS.
That reminds me of something I've been wondering about -
On Fri, Feb 11, 2011 at 12:16 AM, Bill Moran wrote:
> The big caveat is that 99.9% of the database changes don't fall into those
> "nontrivial" categories, and dbsteward makes those 99.9% of the changes
> easy to do, reliable to reproduce, and easy to track.
>
My experience is maybe more like 95%
In response to Glenn Maynard :
> On Thu, Feb 10, 2011 at 6:44 PM, Bill Moran wrote:
>
> > dbsteward can do downgrades ... you just feed it the old schema and
> > the new schema in reverse of how you'd do an upgrade ;)
> >
> > Oh, also, it allows us to do installation-specific overrides. We use
>
On Thu, Feb 10, 2011 at 6:44 PM, Bill Moran wrote:
> dbsteward can do downgrades ... you just feed it the old schema and
> the new schema in reverse of how you'd do an upgrade ;)
>
> Oh, also, it allows us to do installation-specific overrides. We use
> this ONLY for DML for lookup lists where so
>
> Don't the bash scripts get checked in to .../perforce/cvs/svn/git/...?
> Aren't they part of the resources of the project(s)?
Yep - they absolutely are. The issue is that there're multiple branches
*potentially* having new scripts committed. Fortunately it's rare as the
release branches
>
> So, 10.0 at 10057.
> 11.0 at 11023.
>
> then 10.1 needs some fixes so db is bumped to 10058.
>
> Then, later, you can upgrade 10057 to 11023, but you cant get 10058 to 11023.
>
> Humm... maybe you need smarter upgrade scripts? Would having logic in the
> script help? Something like:
>
>
On 11/02/2011, at 9:59 AM, Thomas Kellerer wrote:
> Royce Ausburn wrote on 10.02.2011 22:38:
>> I'm really interested to hear how you guys manage schema upgrades in
>> the face of branches and upgrading from many different versions of
>> the database.
>
> We are quite happy with Liquibase. You c
On 02/10/2011 04:44 PM, Bill Moran wrote:
> In response to Rob Sargent :
>>
>> On 02/10/2011 03:59 PM, Bill Moran wrote:
>>> In response to Rob Sargent :
I for one will be waiting to see your dbsteward. How does it compare
functionally or stylistically with Ruby's migration tools (whic
On 02/10/2011 02:38 PM, Royce Ausburn wrote:
> Hi all,
>
> My company is having trouble managing how we upgrade schema changes across
> many versions of our software. I imagine this is a common problem and
> there're probably some neat solutions that we don't know about.
>
> For the last 1
Bill Moran wrote on 11.02.2011 00:37:
Anyway ... based on nothing more than a quick scan of their quickstart
page, here are the differences I see:
* Liquibase is dependent on you creating "changesets". I'm sure this
works, but we took a different approach with dbsteward. dbsteward
expects
In response to Rob Sargent :
>
> On 02/10/2011 03:59 PM, Bill Moran wrote:
> > In response to Rob Sargent :
> >> I for one will be waiting to see your dbsteward. How does it compare
> >> functionally or stylistically with Ruby's migration tools (which I found
> >> to be pretty cool and frustratin
In response to Thomas Kellerer :
> Bill Moran wrote on 10.02.2011 23:59:
> > The overview:
> > You store your schema and data as XML (this is easy to migrate to, because
> > it includes a tool that makes the XML from a live database)
> > Keep your XML schema files in some RCS.
> > When it's time f
On Thu, 10 Feb 2011 17:59:30 -0500, Bill Moran
wrote:
The overview:
You store your schema and data as XML (this is easy to migrate to,
because
it includes a tool that makes the XML from a live database)
We're doing a similar thing here except we're a Lisp shop so our
schema is defined as
On 02/10/2011 03:59 PM, Bill Moran wrote:
> In response to Rob Sargent :
>
>> Top-posting is frowned upon by some (not me), but since Bill started it...
>
> Oops ... the weird thing is that I'm usually really anal about not top-
> posting ...
>
>> I for one will be waiting to see your dbstewar
Bill Moran wrote on 10.02.2011 23:59:
The overview:
You store your schema and data as XML (this is easy to migrate to, because
it includes a tool that makes the XML from a live database)
Keep your XML schema files in some RCS.
When it's time for a new deployment, you run the dbsteward tool agains
In response to Rob Sargent :
> Top-posting is frowned upon by some (not me), but since Bill started it...
Oops ... the weird thing is that I'm usually really anal about not top-
posting ...
> I for one will be waiting to see your dbsteward. How does it compare
> functionally or stylistically wi
Royce Ausburn wrote on 10.02.2011 22:38:
I'm really interested to hear how you guys manage schema upgrades in
the face of branches and upgrading from many different versions of
the database.
We are quite happy with Liquibase. You can simply run it against a database and tell it
to migrate it t
In response to Andy Colson :
> On 2/10/2011 4:18 PM, Bill Moran wrote:
> >
> > We have this kickass solution we built at work called dbsteward that
> > just takes care of all of this for us, automatically. You just give
> > it the new version and the old version and it generates update statements
Top-posting is frowned upon by some (not me), but since Bill started it...
I for one will be waiting to see your dbsteward. How does it compare
functionally or stylistically with Ruby's migration tools (which I found
to be pretty cool and frustrating all in one go).
On 02/10/2011 03:18 PM, Bill
On 2/10/2011 4:18 PM, Bill Moran wrote:
We have this kickass solution we built at work called dbsteward that
just takes care of all of this for us, automatically. You just give
it the new version and the old version and it generates update statements
to feed into PG.
The reason I'm bringing th
We have this kickass solution we built at work called dbsteward that
just takes care of all of this for us, automatically. You just give
it the new version and the old version and it generates update statements
to feed into PG.
The reason I'm bringing this up is that we're working to release
dbs
On 2/10/2011 4:14 PM, Andy Colson wrote:
On 2/10/2011 3:38 PM, Royce Ausburn wrote:
Hi all,
My company is having trouble managing how we upgrade schema changes
across many versions of our software. I imagine this is a common
problem and there're probably some neat solutions that we don't know
a
On 2/10/2011 3:38 PM, Royce Ausburn wrote:
Hi all,
My company is having trouble managing how we upgrade schema changes across many
versions of our software. I imagine this is a common problem and there're
probably some neat solutions that we don't know about.
For the last 10 years we have be
Hi all,
My company is having trouble managing how we upgrade schema changes across many
versions of our software. I imagine this is a common problem and there're
probably some neat solutions that we don't know about.
For the last 10 years we have been writing bash shell scripts essentially
33 matches
Mail list logo
