[asterisk-dev] Alembic in 12 SVN

[Russell Bryant]

On Tue, Mar 18, 2014 at 10:07 AM, Matthew Jordan <mjordan at digium.com> wrote:

> On Tue, Mar 18, 2014 at 8:31 AM, Russell Bryant
> <russell at russellbryant.net> wrote:
> > On Mon, Mar 17, 2014 at 1:01 PM, Joshua Colp <jcolp at digium.com> wrote:
> >>
> >> Matthew Jordan wrote:
> >>
> >> <snip>
> >>
> >>
> >>>
> >>> Technically, it's probably not hard. I wonder how horrible it'd be for
> >>> end users, however.
> >>>
> >>
> >> Probably pretty horrible, since it's basically changing everything.
> >
> >
> > Well ... you completely drop support for anyone that has already run the
> > scripts.
> >
> > How advertised / documented is it?  It may be new enough that nobody is
> > truly relying on it yet.  That's my guess, honestly.
> >
> > You could probably provide some scripts to manually fix an existing
> database
> > to deal with the change.  That sounds like a pain and probably not worth
> it,
> > though.
> >
> > If you want to rework it, I would just do it ASAP and cover it in release
> > notes.  If you go through this effort, I would also add an automated test
> > that verifies that all migrations are linear to catch these problems
> ASAP in
> > the future.  You could do something like the existing "validate-docs"
> > Makefile target that only runs if dev mode is on.  Add a
> > "validate-linear-migrations" target that runs in dev mode or something
> like
> > that.
> >
>
> I'd prefer to do it now and get it done. Better to suffer the pain now
> rather than during an LTS - but a quick e-mail to the -users list may
> be in order.
>
> Having a make target that tests this is a good idea - we already have
> something similar in mkrelease when it generates the SQL scripts for
> the tarballs, and we have a Bamboo plan that just tests make targets.
> I'll add that to the list.
>
>
Back to the original issue though ... the problem was that there wasn't a
way to catch non-linear migrations.  That can be fixed with some quick
validation.

This also led to potentially wanting to split up migrations per module.
 The reason it was all together in the first place was based on the
assumption that if someone was using realtime, they're likely going to want
it for *all* modules.  Also, having a separate database per module for just
config seems pretty excessive, and honestly a bit of a pain.  When doing
installs, upgrades, and backups you will have to make a list of all of the
different databases you need to mess with.  After thinking about it more,
it sounds like a worse user experience for just a little bit of developer
convenience.

-- 
Russell Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140318/7d6f42e4/attachment.html>