Merge lp:~niemeyer/storm/bug-620615 into lp:storm
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Merged at revision: | 377 | ||||
| Proposed branch: | lp:~niemeyer/storm/bug-620615 | ||||
| Merge into: | lp:storm | ||||
| Diff against target: |
124 lines (+39/-16) 4 files modified
NEWS (+2/-0) storm/store.py (+18/-14) tests/store/base.py (+18/-0) tests/zope/testing.py (+1/-2) |
||||
| To merge this branch: | bzr merge lp:~niemeyer/storm/bug-620615 | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Thomas Herve (community) | 2010-10-14 | Needs Information on 2010-10-17 | |
| Jamu Kakar (community) | Approve on 2010-10-17 | ||
|
Review via email:
|
|||
Description of the Change
That's a test and fix for bug #620615.
| Thomas Herve (therve) wrote : | # |
[1] The value of replace_
[2] Previously the check was only done when keep_defined was True, now it's only done if keep_defines is False. Shouldn't it be done in both cases?
Thanks!
| Gustavo Niemeyer (niemeyer) wrote : | # |
@Jamu,
[1] [2]
Both done, thanks!
@Thomas,
> [1] The value of replace_
> understand that it's probably tricky to raise this exception, but can you
> explain me why the value is set differently in some cases?
Good point. I've added an additional test doing the counter logic by using
reload (the lazy value should be discarded).
> [2] Previously the check was only done when keep_defined was True, now it's
> only done if keep_defines is False. Shouldn't it be done in both cases?
It is actually done in both cases. Look at how "is_unknown_lazy" is tracked in both branches. The distinction is in how that fact is handled, which is precisely the bug fix.

[1]
+ def test_bug_ 620615( self):
Please rename this test and add a docstring:
def test_lazy_ value_preserved _with_subsequen t_object_ initialization( self):
"""
If a lazy value has been modified on an object that is subsequently
initialized from the database the lazy value is correctly preserved
and the object is initialized properly. This tests the fix for the
problem reported in bug #620615.
"""
[2]
+ - Fix bug #620615, which caused lazy expressions to cause following
+ loading of objects to explode if unflushed.
It took me a moment to understand this sentence. I think subsequent/ would make it a touch better.
s/following/
Nice work, +1! Thanks for pushing the fix quickly to unblock the 0.18
release process.