New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-db no longer supported. #170

Closed
ashchristopher opened this Issue Oct 6, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@ashchristopher

ashchristopher commented Oct 6, 2014

In DjangoModelFactory, the factory will eventually make a call to _setup_next_sequence regardless of whether we are building or createing. This means the strategy of building an instance, then settings it's destination via save(using='other_db') is no longer valid.

When using factory.BUILD_STRATEGY, it should not be hitting the database at all.

I can mitigate this issue by overriding the _setup_next_sequence() method.

@classmethod
def _setup_next_sequence(cls):
    return 1
@rbarrois

This comment has been minimized.

Show comment
Hide comment
@rbarrois

rbarrois Oct 6, 2014

Member

Yes, that's an issue; however, I don't think the behavior you describe has ever worked in the last 3 years :/

The workaround you've described is the best solution right now.

This issue originates from a feature that says "if you're settings unique fields through factory.Sequence(), two successive script runs should hopefully provide different values"

Member

rbarrois commented Oct 6, 2014

Yes, that's an issue; however, I don't think the behavior you describe has ever worked in the last 3 years :/

The workaround you've described is the best solution right now.

This issue originates from a feature that says "if you're settings unique fields through factory.Sequence(), two successive script runs should hopefully provide different values"

@ashchristopher

This comment has been minimized.

Show comment
Hide comment
@ashchristopher

ashchristopher Oct 6, 2014

In the past, we were able to override the _prepare() method to take into account db routers, but since the refactor, _prepare() is called after _setup_next_sequence.

It does seem odd to me that when using the factory.BUILD_STRATEGY strategy, that we would have to hit the db.

ashchristopher commented Oct 6, 2014

In the past, we were able to override the _prepare() method to take into account db routers, but since the refactor, _prepare() is called after _setup_next_sequence.

It does seem odd to me that when using the factory.BUILD_STRATEGY strategy, that we would have to hit the db.

rbarrois added a commit that referenced this issue Nov 16, 2014

Remove automagic pk-based sequence setup
Related to issues #78, #92, #103, #111, #153, #170

The default value of all sequences is now 0; the automagic
``_setup_next_sequence`` behavior of Django/SQLAlchemy has been removed.

This feature's only goal was to allow the following scenario:

1. Run a Python script that uses MyFactory.create() a couple of times
   (with a unique field based on the sequence counter)
2. Run the same Python script a second time

Without the magical ``_setup_next_sequence``, the Sequence counter would be set
to 0 at the beginning of each script run, so both runs would generate objects
with the same values for the unique field ; thus conflicting and crashing.

The above behavior having only a very limited use and bringing various
issues (hitting the database on ``build()``, problems with non-integer
or composite primary key columns, ...), it has been removed.

It could still be emulated through custom ``_setup_next_sequence``
methods, or by calling ``MyFactory.reset_sequence()``.
@rbarrois

This comment has been minimized.

Show comment
Hide comment
@rbarrois

rbarrois Mar 26, 2015

Member

This issue has been fixed in 13d310f, and will be part of the 2.5.0 release.

Member

rbarrois commented Mar 26, 2015

This issue has been fixed in 13d310f, and will be part of the 2.5.0 release.

@rbarrois rbarrois closed this Mar 26, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment