<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 22 March 2016 at 12:09, Shinobu Kinjo <span dir="ltr"><<a href="mailto:shinobu.kj@gmail.com" target="_blank">shinobu.kj@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Thank you for your comment (inline for my message).<br>
<span class=""><br>
On Tue, Mar 22, 2016 at 11:53 AM, Vega Cai <<a href="mailto:luckyvega.g@gmail.com">luckyvega.g@gmail.com</a>> wrote:<br>
> Let me try to explain some.<br>
><br>
> On 22 March 2016 at 10:09, Shinobu Kinjo <<a href="mailto:shinobu.kj@gmail.com">shinobu.kj@gmail.com</a>> wrote:<br>
>><br>
>> On Tue, Mar 22, 2016 at 10:22 AM, joehuang <<a href="mailto:joehuang@huawei.com">joehuang@huawei.com</a>> wrote:<br>
>> > Hello, Shinobu,<br>
>> ><br>
>> > Yes, as what you described here, the "initialize" in "core.py" is used<br>
>> > for unit/function test only. For system integration test( for example,<br>
>> > tempest ), it would be better to use mysql like DB, this is done by the<br>
>> > configuration in DB part.<br>
>><br>
>> Thank you for your thought.<br>
>><br>
>> ><br>
>> > From my point of view, the tricircle DB part could be enhanced in the DB<br>
>> > model and migration scripts. Currently unit test use DB model to initialize<br>
>> > the data base, but not using the migration scripts,<br>
>><br>
>> I'm assuming the migration scripts are in "tricircle/db". Is it right?<br>
><br>
><br>
> migration scripts are in tricircle/db/migrate_repo<br>
>><br>
>><br>
>> What is the DB model?<br>
>> Why do we need 2-way-methods at the moment?<br>
><br>
><br>
> DB models are defined in tricircle/db/models.py. Models.py defines tables in<br>
> object level, so other modules can import models.py then operate the tables<br>
> by operating the objects. Migration scripts defines tables in table level,<br>
> you define table fields, constraints in the scripts then migration tool will<br>
> read the scripts and build the tables.<br>
<br>
</span>Dose "models.py" manage database schema(e.g., create / delete columns,<br>
tables, etc)?<br></blockquote><div><br></div><div>In "models.py" we only define database schema. SQLAlchemy provides functionality to create tables based on schema definition, which is "ModelBase.metadata.create_all". This is used to initialized the in-memory database for tests currently.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> Migration tool has a feature to<br>
> generate migration scripts from DB models automatically but it may make<br>
> mistakes sometimes, so currently we manually maintain the table structure in<br>
> both DB model and migration scripts.<br>
<br>
</span>Is *migration tool* different from bot DB models and migration scripts?<br></blockquote><div><br></div><div>Migration tool is Alembic, a lightweight database migration tool for usage of SQLAlchemy:</div><div><br></div><div><a href="https://alembic.readthedocs.org/en/latest/">https://alembic.readthedocs.org/en/latest/</a><br></div><div><br></div><div>It runs migration scripts to update database schema. Each database version has one migrate script. After defining "upgrade" and "downgrade" method in the script, you can update your database from one version to another version. Alembic isn't aware of DB models defined in "models.py", users need to guarantee the version of database and the version of "models.py" match.</div><div><br></div><div>If you create a new database, both "ModelBase.metadata.create_all" and Alembic can be used. But Alembic can also be used to update an existing database to a specific version of schema.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
>><br>
>><br>
>> > so the migration scripts can only be tested when using devstack for<br>
>> > integration test. It would better to using migration script to instantiate<br>
>> > the DB, and tested in the unit test too.<br>
>><br>
>> If I understand you correctly, we are moving forward to using the<br>
>> migration scripts for both unit and integration tests.<br>
>><br>
>> Cheers,<br>
>> Shinobu<br>
>><br>
>> ><br>
>> > (Also move the discussion to the openstack-dev mail-list)<br>
>> ><br>
>> > Best Regards<br>
>> > Chaoyi Huang ( joehuang )<br>
>> ><br>
>> > -----Original Message-----<br>
>> > From: Shinobu Kinjo [mailto:<a href="mailto:skinjo@redhat.com">skinjo@redhat.com</a>]<br>
>> > Sent: Tuesday, March 22, 2016 7:43 AM<br>
>> > To: joehuang; khayam.gondal; zhangbinsjtu; shipengfei92; newypei;<br>
>> > Liuhaixia; caizhiyuan (A); huangzhipeng<br>
>> > Subject: Using in-memory database for unit tests<br>
>> ><br>
>> > Hello,<br>
>> ><br>
>> > In "initialize" method defined in "core.py", we're using *in-memory*<br>
>> > strategy making use of sqlite. AFAIK we are using this solution for only<br>
>> > testing purpose. Unit tests using this solution should be fine for small<br>
>> > scale environment. But it's not good enough even it's for testing.<br>
>> ><br>
>> > What do you think?<br>
>> > Any thought, suggestion would be appreciated.<br>
>> ><br>
>> > [1]<br>
>> > <a href="https://github.com/openstack/tricircle/blob/master/tricircle/db/core.py#L124-L127" rel="noreferrer" target="_blank">https://github.com/openstack/tricircle/blob/master/tricircle/db/core.py#L124-L127</a><br>
>> ><br>
>> > Cheers,<br>
>> > Shinobu<br>
>> ><br>
>> > __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Email:<br>
>> <a href="mailto:shinobu@linux.com">shinobu@linux.com</a><br>
>> GitHub:<br>
>> shinobu-x<br>
>> Blog:<br>
>> Life with Distributed Computational System based on OpenSource<br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><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" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Email:<br>
<a href="mailto:shinobu@linux.com">shinobu@linux.com</a><br>
GitHub:<br>
shinobu-x<br>
Blog:<br>
Life with Distributed Computational System based on OpenSource<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>