To finish this thread, I have decided to abandon the attempt. My
solution is to tell the users to avoid doing real work on the staging
server. It exists only to check out new features.
I feel better now.
Thanks Melvyn and Tim
Mike
On 10/11/2016 11:08 AM, Mike Dewhirst wrote:
On 10/11/2016 12:06 AM, Tim Graham wrote:
I see. Although I would be interested to see what you come up with,
@Tim
It is getting there so if you are really interested I'll post it
somewhere when it is working. I'm getting router errors at the moment
which I might be able to workaround by permitting null in a FK fields
during obj.save(using=db). Might ask some questions on this later. I
don't really want to permit null in this particular case.
my initial reaction is that we wouldn't accept a patch for Django to
do this. It seems too complex and brittle.
Having done some work on this I agree with you but disagree with Melvyn.
The task is complex and would be almost impossible to generalise. For
example, from a number of substances the user may have done serious
work on only a few and won't want the others transferred.
So I'm building a facility to transfer one substance at a time. If
there is a future requirement for bulk transfer I can iterate.
The transferred substance might be a mixture in which case I have to
collect the ingredient substances plus the m2m through records which
are effectively the recipe. Some of the ingredients might themselves
be mixtures. Not worrying about that at the moment.
For each substance there are 6 OneToMany, up to 15 OneToOne and two
m2m relationships plus a OneToOne where the sibling has lots of its
own complex relationships including a recursive OneToOne to form a
daisy-chain of history. I'm skipping that one for the moment.
I agree with Melvyn
See below
that it seems unusual to use Django's multi-database facilities to
transfer data between staging and production.
On Wednesday, November 9, 2016 at 4:51:39 AM UTC-5, Melvyn Sopacua
wrote:
On Wednesday 09 November 2016 13:59:35 Mike Dewhirst wrote:
> On 9/11/2016 9:13 AM, Tim Graham wrote:
> > Interesting idea. I'd be interested to here more about the use
case.
>
> Simple. I permitted my users to "play" on the staging site and
now one
> of them wants to transfer their work to the production site.
Your approach is wrong. You think of this as one django project and
trying to cheat under the hood, while in fact they are two different
projects. And by design, staging is not always structually
identical to
production.
@Melvyn
I was wrong to think saveasnew might do the trick.
However, migration is fully implemented so I can easily abort any
transfer if the structures are not identical. As it happens, there are
only two databases at the moment. Staging and production and while
they are not always structurally identical they are currently the same
during testing.
Your best approach is to use serialization with natural keys
Maybe but the complexity and a couple of business rules persuade me to
write code to do it "manually" so I can unit test it. Also, if I get
it going, the user can select a substance to transfer and doesn't have
to bother me.
I also realise it is very brittle so it needs to be revised if the
structure changes.
Thanks for your advice. I appreciate it even if I think I need to
tackle the problem my way.
Cheers
Mike
and a job
scheduler. Cron will do, but there's plenty other schemes allowing
you
to provide feedback about the job queue and expected time of
completion.
-- Melvyn Sopacua
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to django-users+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/ccfa9aef-d1c3-45e0-a894-c07a2701c1aa%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/ccfa9aef-d1c3-45e0-a894-c07a2701c1aa%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/2179e6df-3317-932b-9e8f-041f8ba7ee5b%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.
