<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <i>On 23.01.2015 23:39, Ruslan Kamaldinov wrote:</i><i><br>
    </i><i>
    </i>
    <blockquote type="cite"><i>1. Use ModelsMigrationsSync from [2] in
        tests to make sure that
        SQLAlchemy models are in sync with migrations. Usage example can
        be
        found at [3]</i>
      <p>
      </p>
    </blockquote>
    Seems like it is a great helper, as I understand it runs all
    migrations and then compares DB state with models state and throws
    an error if they are out of sync.<br>
    What I don't understand - why they still manually write checks for
    every migration [1]? This is redundant, because <tt>ModelsMigrationsSync
    </tt>already does the job testing that DB is in sync with models. <br>
    <br>
    By the way in Heat project they do the same thing [2]. What am I
    missing?<br>
    <br>
    [1]
<a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/sahara/tree/sahara/tests/unit/db/migration/test_migrations.py#n402">http://git.openstack.org/cgit/openstack/sahara/tree/sahara/tests/unit/db/migration/test_migrations.py#n402</a><br>
    [2]
<a class="moz-txt-link-freetext" href="https://github.com/openstack/heat/blob/7d4c4030c591ef5994db4327d66d353ad83c6ea8/heat/tests/db/test_migrations.py#L288">https://github.com/openstack/heat/blob/7d4c4030c591ef5994db4327d66d353ad83c6ea8/heat/tests/db/test_migrations.py#L288</a><br>
    <br>
    <br>
    <i>On 23.01.2015 23:39, Ruslan Kamaldinov wrote:</i><i><br>
    </i>
    <blockquote type="cite"><i>2. Populate DB schema from SQLAlchemy
        models in unit-tests which
        require access to DB</i></blockquote>
    You mean - using these tools [3]?<br>
    <br>
    [3]
<a class="moz-txt-link-freetext" href="http://docs.sqlalchemy.org/en/rel_0_9/core/metadata.html#creating-and-dropping-database-tables">http://docs.sqlalchemy.org/en/rel_0_9/core/metadata.html#creating-and-dropping-database-tables</a><br>
    <br>
    <br>
    <i>On 23.01.2015 23:39, Ruslan Kamaldinov wrote:</i><i><br>
    </i>
    <blockquote type="cite"><i>3. Wipe out everything related to SQLite
        from DB migrations code </i><i><br>
      </i><i>4. Recommend all developers to use MySQL when they run
        Murano locally </i><i><br>
      </i><i>5. For those who still insist on SQLite we can provide a
        command line option which would generate database schema from
        SQLAlchemy metadata. This should be declared as development only
        feature, not supported for any kind of production deployments </i><br>
    </blockquote>
    In what conditions 5) will fail? I see only these cases:<br>
    - If data migrations would be introduced and Murano would require
    some data in DB to work correctly.<br>
    - If Murano would use some database-specific features (stored
    procedures etc).<br>
    <br>
    There are good chances that these cases will never happen in
    reality, as I understand, so I tend to agree.<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
With kind regards, Andrew Pashkin.
cell phone - +7 (985) 898 57 59
Skype - waves_in_fluids
e-mail - <a class="moz-txt-link-abbreviated" href="mailto:apashkin@mirantis.com">apashkin@mirantis.com</a></pre>
  </body>
</html>