> > > 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 catal
On Sun, Sep 13, 2015 at 12:20:49PM +0200, Erik Huelsmann wrote:
> On Sat, Sep 12, 2015 at 4:27 PM, R. Ransbottom 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
On Sat, Sep 12, 2015 at 4:27 PM, R. Ransbottom wrote:
> On Fri, Sep 11, 2015 at 02:35:58PM +0200, Erik Huelsmann wrote:
>
> > > For myself, I am leaning toward setting up a local repository.
> > > I would have liked to avoid adding a larger version control
> > > requirement for my eventual replac
On Fri, Sep 11, 2015 at 02:35:58PM +0200, Erik Huelsmann wrote:
> > For myself, I am leaning toward setting up a local repository.
> > I would have liked to avoid adding a larger version control
> > requirement for my eventual replacement.
> sure, can you describe how you think you will track the
Hi Rob,
On Thu, Sep 10, 2015 at 9:53 PM, R. Ransbottom wrote:
> My question about user database changes was sparked by a vague
> remembrance of a text saying to use inheritance. Apparently,
> I misremembered.
>
> For myself, I am leaning toward setting up a local repository.
> I would have lik
> Well, other than the standard Perl steps "copy to blib" and "manify POD",
>> we don't really have build steps of our own. I'm indeed proposing that we
>> have a build step. I envision it to be something like this:
>>
>> * Create PostgreSQL database
>> * Play Sqitch scripts
>> * Dump schema from t
My question about user database changes was sparked by a vague
remembrance of a text saying to use inheritance. Apparently,
I misremembered.
For myself, I am leaning toward setting up a local repository.
I would have liked to avoid adding a larger version control
requirement for my eventual rep
Hi John,
Thanks for your reaction. I went to the sqitch mailing list for a bit more
information, hence my later reaction.
> Some more info:
>
> It seems Sqitch wants to address the issue of multiple branches receiving
> the same patches and upgrading from one branch to another, like we want to
>
Hi,
On 08/26/2015 01:18 PM, Erik Huelsmann wrote:
Some more info:
It seems Sqitch wants to address the issue of multiple branches
receiving the same patches and upgrading from one branch to another,
like we want to support: https://github.com/theory/sqitch/issues/200
I reviewed some of t
On Wed, Aug 26, 2015 at 12:13 PM, Erik Huelsmann wrote:
> Hi,
>
> Hi all,
>>
>> There are a few issues that I have with the way we currently handle
>> database schema changes.
>>
>> Current situation
>>
>>
>>
>> We have a main schema file for the table definitions and a number of
>>
Some more info:
It seems Sqitch wants to address the issue of multiple branches receiving
the same patches and upgrading from one branch to another, like we want to
support: https://github.com/theory/sqitch/issues/200
Regards,
Erik.
On Wed, Aug 26, 2015 at 9:13 PM, Erik Huelsmann wrote:
> Hi,
Hi,
Hi all,
>
> There are a few issues that I have with the way we currently handle
> database schema changes.
>
> Current situation
>
>
>
> We have a main schema file for the table definitions and a number of
> modules with stored procedures grouped by "subject".
>
> Next to that, th
I thought I sent my response but I guess something went wrong. Sending
again.
Remarks in-line
On Wed, Aug 26, 2015, 14:23 Erik Huelsmann wrote:
Hi all,
There are a few issues that I have with the way we currently handle
database schema changes.
Current situation
We have a main
Hi all,
There are a few issues that I have with the way we currently handle
database schema changes.
Current situation
We have a main schema file for the table definitions and a number of
modules with stored procedures grouped by "subject".
Next to that, there's a "Fixes" file, whic
14 matches
Mail list logo