T258401: Stop deleting important objects found in commits #128
Conversation
I thought exactly the same thing when reading the PR. The top-level |
| self.run('playback', '/') | ||
| assert 'acl_users' not in self.app.some_module.objectIds() | ||
|
|
||
| def test_keep_acl_norecurse(self): |
There was a problem hiding this comment.
Tipp: If you have two very similar tests that only differ in a few lines, you can write one test with two variants using pytest.parametrize.
perfact/zodbsync/zodbsync.py
Outdated
| del_ids = [ | ||
| a for a in srv_contents | ||
| if a not in contents and | ||
| (path != '/acl_users' and a != 'acl_users') |
There was a problem hiding this comment.
Why doesn't this prevent the deletion of /some_module/acl_users in recursive mode? I'm a bit confused...
There was a problem hiding this comment.
I think it does prevent it, but the test does not notice because of some transaction shenanigans. I stepped with the debugger into the playback and noticed that both fs_contents and srv_contents were empty, so nothing was deleted. Not sure why the first check for the presence of acl_users in the tests does not fail though...
There was a problem hiding this comment.
To explain: If we simply manipulate something with directly accessing self.app, this automatically opens a transaction. When the next self.run(...) is executed, this usually also starts a transaction, aborting the already open transaction. Therefore the creation of /some_module and /some_module/acl_users was never commited, but visible in the first check (since it was still the same transaction), but no longer visible once the playback started.
There was a problem hiding this comment.
I guess playback explicitly starts a new transaction (to be able to roll it back later) while record does not (because it does not expect to change anything inside the Data.FS).
No description provided.