Database Caching

[rdohms]

@guilhermeblanco told me you are working on the functional side of things, but i just want to ask a few questions so that i can find temporary fixes to allow us to use them for now.

The one problem I see now is that the DB caching only takes into consideration one thing: the md5 of the list of fixtures, it does not invalidate cache based on schema changes or on changes inside the fixtures.

What are the plans or ideas towards fixing this? will it rely on the fixture bundle or something undocumented yet?

[guilhermeblanco]

@rdohms that is a series of tricky questions.

When altering your schema, you already have to clear your cache, so this already invalidates the first answer. The second one, would require a track of each entity loaded, which we do have in ProxyReferenceRepository. The problem comes when you change content inside of these fixtures. Adding/removing entries could be somehow supported by hitting the ProxyReferenceRepository and the ones missing would be executed. Now when fields in an already loaded fixture changes, that would be no way to track that unless you merge the entity, hydrates new content and then check if it's dirty or not. At this point, you completely defeated the purpose of this optimization.

That's why I consider that we have no plans to support any of them because of its complexity. It's just better to remove your cache/test folder and run again.

With a few tweaks ( http://kriswallsmith.net/post/27979797907/get-fast-an-easy-symfony2-phpunit-optimization ), you can already speed up consecutive executions without the burden of initializing the container over and over in your test suite.

[matthiasnoback]

Well, to me the most straight-forward solution would be to also take the latest modified time of the fixture files into consideration. That would immediately trigger a build when you make a change in the fixture file, right?

[robocoder]

The timestamp idea has been used in liip functional test bundle (and elsewhere).