gsoc_submission.md

Here's what I've managed to accomplish from the original project's goals:

• Adapt the parallel test runner to use spawn
• Implement an Oracle cloning method

Look at the forum post for detailed week-by-week updates over the state of play

Here's the summary of code changes:

Code changes by backends

Base

Added setup_worker_connection

I moved the base worker connection logic initially under _init_worker to connection.creation. Backends can override this method to connect worker connections how they see fit.

SQLite

Implementing _clone_test_db for spawned processes

SQLite now clones the default in-memory database into an on-disk database for each alias.

Overriding setup_worker_connection for spawned processes

During the initialization of spawned workers, the saved on-disk databases are loaded back into in-memory databases for each worker.

MySQL

No changes were done in this backend other than clean-up due to unexpected bugs:

• Test loader accesses MySQL before database is created
• MySQL schema tests fail when table names are case-insensitive

PostgreSQL

• PostgreSQLHStoreTestCase was added for spawn-specific failures.
• PostgreSQL inspectDB tests fail on Windows. This was Windows-specific

Oracle

Overriding get_test_db_clone_settings

The Oracle backend differs than other backends in that the database name depends on settings_dict['USER'] instead of the expected settings_dict['NAME']. The overriden method returns the appropriate settings_dict altered for Oracle.

Adding suffix parameter to _get_test_db_params

If suffix is not None, the suffix will be added to USER, PASSWORD, TBLSPACE, TBLSPACE_TMP.

Implementing a cloning method using expdp/impdp

The Oracle backend now supports cloning using expdp/impdp, creating one dump for each alias, and importing the database for each clone.

Code changes for spawn-specific failures

• Aforementioned PostgreSQLHStoreTestCase
• Rewriting check_framework test to accomodate lack of shared state in spawned process
• Code change in autoreload.py to check for __mp_main__ not just __main__

I can happily confirm that you can run your tests on parallel using any backend on Windows without getting Windows-specific errors at the moment.

Some polishing is required however in the following:

• Running tests in parallel and in reverse on Windows I plan on continuing to tackle the --reverse-specific failures. That's the only remaining clean-up I have.

Some tickets that were inspired by the work done in this GSoC project:

• Add optional timing outputs (This has been merged)
• Parallelize database cloning process (WIP)

Hello sir,
I want to contribute to your project. I have contributed already in two different DJANGO related projects at Girlscript summer of code.
This forum isn't sensing me good and I am super confused and so I am dropping this message here. I am sorry if it's not supposed to be here.
Please help me out so that I can contribute my part of learning and get experience in the open source sphere.
Thank you. Regards.