(Discussion) Reused DB Template Load Factory

[ivanthewebber]

I wanted to poll your experience on a couple possible improvements.

Currently the load logic would be ran once per database creating a template for each, but for most users it probably only needs ran once for a single template that can be reused. Thus, I think a helper load factory function could be useful to deduplicate. It might look like following pseudocode:

import multiprocessing

def init_db_factory(load_template: callable):
    template_ready = multiprocessing.Value('b', False)

    def check_bool():
           if not template_ready:
               raise ValueError()

    def inner(*args, **kwargs):
        if not os.getenv("PYTEST_XDIST_WORKER"):
            # initialize db template as usual
            load_template(*args, **kwargs)
            template_ready.set(True)
        else:
            # wait for template to exist
            retry(check_bool, possible_exception=ValueError)

Of course some other logic/config to reuse the template name might need adjusted.

What are your thoughts?

Additionally I've observed that the template approach might be slower for the many tables in our database, do you have thoughts on that? Perhaps being able to toggle easily would make the library more useful and easier to find the best configuration for a project's individual differences.

Finally, we already have a lot of fixtures that are often reused that add some data into the database/session for testing. My understanding is that replacing these with pre-populated data in the template DB should give us some test suite speed improvements?

[fizyk]

I'll start from the end:

Finally, we already have a lot of fixtures that are often reused that add some data into the database/session for testing. My understanding is that replacing these with pre-populated data in the template DB should give us some test suite speed improvements?

Yes, that was the idea. To run migrations, and then if required, load some commen data set to the database and then create per-test databases based on that template (it's around as fast as transactions, and gives more opportunities). (I've recently copied that behaviour in go, it isn't that pretty, but it works pretty well.)

Additionally I've observed that the template approach might be slower for the many tables in our database, do you have thoughts on that? Perhaps being able to toggle easily would make the library more useful and easier to find the best configuration for a project's individual differences.

Unfortunately, I haven't benchmarked this approach. All I did was some hand-run testing, and those wouldn't have more than a few tables.

And to the main question... That means (operating on current entities in the plugin) the proc/noproc fixture would have to be run on xdist master, and only clients would work on actual workers, creating databases out of the template. I think that would be doable. Though nut to crack, but doable. The real question would be how to wrap it nicely in a pytest-plugin and keep it compatible with the current approach... Flags, switches? Huh...

[fizyk]

I hooked up coderabbit to my OS repositories, and it did pretty good diagram in one of the pr (it's as useful as scary):

fizyk/pyramid_fullauth#721 (comment)

I need to include it in a readme or finally go back to creating docs....