<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/14/15 7:12 PM, Angus Salkeld
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAA16xcxbBGRN3pjEYnO+tYrR=sZ9HXA4yqc27mt2E48fr4TpsQ@mail.gmail.com"
      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 moz-do-not-send="true"
                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
                class=""><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 class="HOEnZb">
                <div class="h5"><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>
    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.<br>
    <br>
    <br>
    <blockquote
cite="mid:CAA16xcxbBGRN3pjEYnO+tYrR=sZ9HXA4yqc27mt2E48fr4TpsQ@mail.gmail.com"
      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 class="HOEnZb">
                <div class="h5">
                  <br>
                  <br>
                  <br>
__________________________________________________________________________<br>
                  OpenStack Development Mailing List (not for usage
                  questions)<br>
                  Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
                    target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
                  <a moz-do-not-send="true"
                    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 class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>