<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 15, 2015 at 11:54 AM, Mike Bayer <span dir="ltr"><<a href="mailto:mbayer@redhat.com" target="_blank">mbayer@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <br>
    <br>
    <div>On 5/14/15 7:12 PM, Angus Salkeld
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Fri, May 15, 2015 at 4:46 AM, Mike
            Bayer <span dir="ltr"><<a href="mailto:mbayer@redhat.com" target="_blank">mbayer@redhat.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
                <br>
                On 5/14/15 11:58 AM, Doug Hellmann wrote:<br>
                <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <br>
                  At one point we were exploring having both
                  sqlalchemy-migrate and<br>
                  alembic run, one after the other, so that we only need
                  to create new<br>
                  migrations with alembic and do not need to change any
                  of the existing<br>
                  migrations. Was that idea dropped?<br>
                </blockquote>
                <br>
              </span>
              to my knowledge the idea wasn't dropped.   If a project
              wants to implement that using the oslo.db system, that is
              fine, however from my POV I'd prefer to just port the
              SQLA-migrate files over and drop the migrate dependency
              altogether.  Whether or not a project does the "run both"
              step as an interim step doesn't affect that effort very
              much.
              <div>
                <div><br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Hi Mike</div>
            <div><br>
            </div>
            <div>Just a quick question: How would the alembic scripts
              know where to start the migration from if the current
              installation had been up until that</div>
            <div>point been using migrate (I believe both alembic and
              migrate write to a small table what the current version
              is, would you look for that?)?</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Thinking about that issue, the most controllable and clean-break way
    to do it would be to add support to Alembic itself that augments its
    own handling of the "alembic_version" table to transfer data from an
    existing sqlalchemy_migrate table.  I can even see using traditional
    alembic hex-style version numbers in migration files which then also
    can refer to their previous numerically-based migrate file.    <br>
    <br>
    It's not unreasonable that Alembic would support some standard
    upgrade path from Migrate, the only other migration tool SQLAlchemy
    has ever had, so I'd just add that as a feature.</div></blockquote><div><br></div><div>Thanks. Would you suggest we hold off moving to alembic (in Heat) until you have this ironed out? I just want to make sure we</div><div>don't do this prematurely.</div><div><br></div><div>-Angus<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
    <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>-Angus</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div>
                <div>
                  <br>
                  <br>
                  <br>
__________________________________________________________________________<br>
                  OpenStack Development Mailing List (not for usage
                  questions)<br>
                  Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
                  <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </span></div>

<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>