<p dir="ltr"></p>
<p dir="ltr">On Oct 5, 2016 4:19 PM, "Rodrigo Ramírez Norambuena" <<a href="mailto:decipher.hk@gmail.com">decipher.hk@gmail.com</a>> wrote:<br>
><br>
> On Tue, 2016-10-04 at 16:45 -0600, George Joseph wrote:<br>
> > Several folks have requested the ability to use the same schema for<br>
> > their cdr, config and voicemail tables.  Alembic currently has an<br>
> > issue with this because the default name of the table alembic uses to<br>
> > track which revision the database is at is named 'alembic_version'<br>
> > with no qualifying information in it.  The result is that if you<br>
> > attempt to use the same schema for 2 trees, alembic will complain<br>
> > that the revisions are out of sync. <br>
> ><br>
> > To address this, I've put a patch[1] up on gerrit that renames the<br>
> > 'alembic_version' table to 'alembic_version_<tree>'  the next time<br>
> > you run alembic for a tree.  For cdr for instance, the new table<br>
> > would be named 'alembic_version_cdr'.  It would only be renamed it it<br>
> > contained a revision that matches the tree your're working with.<br>
> ><br>
> > Let's say you have an existing config tree in the 'asterisk' schema<br>
> > and wanted to add the cdr table to it.   Assuming your cdr.ini file<br>
> > points to the 'asterisk' schema, when you run 'alembic -c cdr.ini<br>
> > upgrade head', the existing 'asterisk_version' table would be checked<br>
> > to see if it belongs to cdr.  Since it belongs to config not cdr, the<br>
> > existing table is left alone and a new 'alembic_version_cdr' table is<br>
> > created and the upgrade is performed to create the cdr table.<br>
> ><br>
> > The next time you run alembic on the config tree, the<br>
> > 'alembic_version' table is checked again and since it does belong to<br>
> > config, it's renamed to 'alembic_version_config'.<br>
> ><br>
> > No existing data tables are renamed or altered and their data isn't<br>
> > touched unless of course that was the point of the alembic script in<br>
> > the first place.<br>
> ><br>
> > So why this email?   We just wanted to make sure that nobody has an<br>
> > issue with renaming that table.  Hopefully nobody is actually using<br>
> > that table for anything but even if you're not, we don't want you to<br>
> > be surprised if you notice the change.<br>
> ><br>
> > Speak up now if you have an issue with this.<br>
> ><br>
> > [1] <a href="https://gerrit.asterisk.org/4018">https://gerrit.asterisk.org/4018</a><br>
> ><br>
> > <br>
><br>
> Cool!,<br>
><br>
> I had the issue when I created the patch [1].<br>
><br>
> Well, when that it's merge into the master I'll modify the patch.</p>
<p dir="ltr">Yep.  You're going to want to copy the new env.py script from one of the other directories.  </p>
<p dir="ltr">><br>
> Regards!<br>
><br>
> 1: <a href="https://gerrit.asterisk.org/#/c/4012/">https://gerrit.asterisk.org/#/c/4012/</a><br>
><br>
><br>
> --<br>
> _____________________________________________________________________<br>
> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a> --<br>
><br>
> asterisk-dev mailing list<br>
> To UNSUBSCRIBE or update options visit:<br>
>    <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></p>