Adding views to a custom db when there are existing migrations

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.

Best regards
Pawel

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.

Best regards
Pawel

--

--- You received this message because you are subscribed to the Google
Groups "CommCare Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Simon Kelly
Senior Engineer | Dimagi South Africa

Hi Pawel,

Here's my proposed solution to this:

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:

The only other way we do it is via the settings file:
commcare-hq/settings.py at master · dimagi/commcare-hq · GitHub

On 3 April 2014 15:49, Paweł Reise preise@soldevelo.com 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.

Best regards
Pawel

--

--- You received this message because you are subscribed to the Google
Groups "CommCare Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Simon Kelly
Senior Engineer | Dimagi South Africa

--


You received this message because you are subscribed to the Google Groups
"CommCare Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.