<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 18, 2014 at 10:07 AM, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br>

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

<div><br></div><div>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.</div>

<div><br></div><div>-- </div><div>Russell Bryant</div></div></div></div>