according to discussion on the other thread (about providing fixtures
for Pathfinder/m4change project), I'm reposting the problem which we
came across recently.
One other question - is there a better way to handle adding a design
doc with views to a custom database (that is 'commcarehq__m4change')
than the way I do it in the 'tasks.py' file (lines 19-21): https://github.com/SolDevelo/commcare-hq/compare/dimagi:master...M4CHANGE_5?
I tried using Django signals, but 'syncdb' seems to never run for
'custom.m4change' if there are existing migrations in the database. Is
there a better way to do it?
As Cory suggested, it would be good to discuss it and to define a
standard way to do such things.
Please let me know if you need a better context - I'll try to provide
more information.
The only other way we do it is via the settings file:
···
On 3 April 2014 15:49, Paweł Reise wrote:
Hi,
according to discussion on the other thread (about providing fixtures for
Pathfinder/m4change project), I'm reposting the problem which we came
across recently.
One other question - is there a better way to handle adding a design doc
with views to a custom database (that is 'commcarehq__m4change') than the
way I do it in the 'tasks.py' file (lines 19-21): https://github.com/SolDevelo/commcare-hq/compare/dimagi:
master...M4CHANGE_5? I tried using Django signals, but 'syncdb' seems to
never run for 'custom.m4change' if there are existing migrations in the
database. Is there a better way to do it?
As Cory suggested, it would be good to discuss it and to define a standard
way to do such things.
Please let me know if you need a better context - I'll try to provide more
information.
It just uses south's post_migrate signal to call the same thing that the
post_syncdb would call. Not sure if we should try and get this ported to
couchdbkit (I think it would introduce a new dependency on south so
probably not). Thanks simon for the pointers.
What I discovered along the way:
syncdb:
will call the post_syncdb signal for any non-south app on every run
will call the post_syncdb signal for any south app only if a table is
created.
migrate
will call the post_migrate signal for any south app
will not call the post_migrate signal for any non-south app
sync_prepare_couchdb (aka preindex)
calls the signal on all apps. no issues
sync_finish_couchdb (aka deploy)
calls the signal on all apps. no issues.
I think with my change this problem should be fine for both developer
machines and production moving forward. The only minor downside is that
design doc sync gets called twice under new south apps, but this is just a
small performance hit (though may have a larger impact on tests). we should
look into optimizing when we continue to push for faster tests.
thanks for raising this.
Cory
···
On Fri, Apr 4, 2014 at 9:32 AM, Simon Kelly wrote:
according to discussion on the other thread (about providing fixtures for
Pathfinder/m4change project), I'm reposting the problem which we came
across recently.
One other question - is there a better way to handle adding a design doc
with views to a custom database (that is 'commcarehq__m4change') than the
way I do it in the 'tasks.py' file (lines 19-21): https://github.com/SolDevelo/commcare-hq/compare/dimagi:
master...M4CHANGE_5? I tried using Django signals, but 'syncdb' seems
to never run for 'custom.m4change' if there are existing migrations in the
database. Is there a better way to do it?
As Cory suggested, it would be good to discuss it and to define a
standard way to do such things.
Please let me know if you need a better context - I'll try to provide
more information.