<div dir="ltr">Igor,<div><br></div><div>Ryan was able to repeat the issue in his env by checking out the patch set (5) with <span style="font-family:'courier new',monospace;font-size:13px">db().refresh(task_provision) </span>enabled.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 13, 2014 at 3:28 AM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi guys,<div><br></div><div><b>@Roman</b>, we have </div><div><br></div><div> <font face="courier new, monospace">db().refresh(task_provision)</font></div>
<div><br></div><div>since the line above (<font face="courier new, monospace">self._call_silently</font>) may change task status directly in db, not in SQLAlchemy session.</div>
<div><br></div><div><b>@Andrew</b>, it's really strange. I just checkout your request, return refreshing task and run tests.</div><div>As a result, I have no failed tests in the <font face="courier new, monospace">test_task_manager.py</font><font face="arial, helvetica, sans-serif">.</font></div>
<div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Are you sure your environment is ok?</font></div><div><br></div><div>Thanks,</div><div>Igor</div></div><div class="HOEnZb">
<div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Apr 13, 2014 at 12:57 PM, Roman Podoliaka <span dir="ltr"><<a href="mailto:rpodolyaka@mirantis.com" target="_blank">rpodolyaka@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Andrew,<br>
<br>
I believe, it's just the way SQLAlchemy Session works: all the changes<br>
you've made within a session aren't propagated to the db (read: no<br>
actual queries are issued) until you explicitly do:<br>
<br>
- flush(), or<br>
- commit() (as commit() calls flush() first), or<br>
- Query - one(), first(), all(), update(), delete() - as these are<br>
actions that can only be performed by contacting the db.<br>
<div><br>
>>> db().refresh(task_provision) call appeared to be reseting the object<br>
<br>
</div>Yes, and this is exactly what it is supposed to do: get the current<br>
state of the model instance from the db (basically: select * from<br>
model_table where id = instance_primary_key_value). This means, that<br>
all the changes you've made, but haven't flushed yet, will be lost.<br>
I've made a small snippet to see this in action:<br>
<a href="http://xsnippet.org/359888/" target="_blank">http://xsnippet.org/359888/</a> (with logging of SQL queries enabled)<br>
<br>
I hope this helps. I'm just wondering, why would you want to call<br>
refresh() there?<br>
<br>
Thanks,<br>
Roman<br>
<div><div><br>
On Sat, Apr 12, 2014 at 1:33 AM, Andrew Woodward <<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>> wrote:<br>
> Recently in one of my changes [1] I was fighting with one of the unit<br>
> tests showing a failure for a test which should have been outside the<br>
> sphere of influence.<br>
><br>
> Traceback (most recent call last):<br>
> File "/home/andreww/.virtualenvs/fuel/local/lib/python2.7/site-packages/mock.py",<br>
> line 1190, in patched<br>
> return func(*args, **keywargs)<br>
> File "/home/andreww/git/fuel-web/nailgun/nailgun/test/integration/test_task_managers.py",<br>
> line 65, in test_deployment_task_managers<br>
> self.assertEquals(provision_task.weight, 0.4)<br>
> AssertionError: 1.0 != 0.4<br>
><br>
> After walking through a number of times and finally playing with it we<br>
> where able to find that the db().refresh(task_provision) call appeared<br>
> to be reseting the object. This caused the loss of the weight being<br>
> set to 0.4 (1.0 is the model default). db().commit(), db().flush() and<br>
> no call to db all caused the test to pass again.<br>
><br>
> Does anyone have any input on why this would occur? The oddly odd part<br>
> is that this test doesn't fail outside of the change set in [1]<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/78406/8/nailgun/nailgun/task/manager.py" target="_blank">https://review.openstack.org/#/c/78406/8/nailgun/nailgun/task/manager.py</a><br>
><br>
> --<br>
> Andrew<br>
> Mirantis<br>
> Ceph community<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</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>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</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></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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><br clear="all"><div><br></div>-- <br><div dir="ltr">Andrew<div>Mirantis</div><div>Ceph community</div></div>
</div>