Mike,
Yeah. Makes sense. Good thought about the UUIDs! My success
was due partly to the fact that I could afford to move entire
tables,
not just selected rows, and could move all related tables as well.
Trying to move just some of a related set of data from one DB to
another with each DB generating its own set of auto-incremented
PKs would have been a problem.
On 1/2/17 11:04 PM, Mike Dewhirst
wrote:
On 3/01/2017 12:32 PM, Fred Stluka wrote:
Mike,
Maybe you don't need a custom DB manager. Perhaps a simple
DB router would suffice? It's a Django way to specify which DB
to use based on which model is being used, whether it is being
read/written, etc.
That's the approach I took. The essence of the problem: it ain't
simple. There are many and varied relationships and any transfer
of *related sets* of data to another database means transferring
existing PKs which tie the sets together. Maybe if it was a
foreseen design criterion we would have used UUIDs instead of
incrementing integer ids.
The DB router is designed for naturally segmented schemas being on
different databases. My attempt was against the grain.
Cheers
Mike
See:
-
https://docs.djangoproject.com/en/dev/topics/db/multi-db/#topics-db-multi-db-routing
--Fred
------------------------------------------------------------------------
Fred Stluka -- mailto:f...@bristle.com --
http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of
service!
Open Source: Without walls and fences, we need no Windows or
Gates.
------------------------------------------------------------------------
On 11/4/16 12:37 AM, Mike Dewhirst wrote:
(this one might be easier to read)
I am planning some utility helper code to push selected
records and their children from our staging database into the
production database. The current database would be 'default'
and I could add a second one called 'production' then read
from 'default' and write to 'production'. (I need to check we
are on the staging server).
The docs say ...
https://docs.djangoproject.com/en/1.8/topics/db/multi-db/#using-managers-with-multiple-databases
... but I don't quite understand. There are no custom managers
involved; only the out-of-the-box MyModel.objects.
Q1. Should I be using db_manager()?
The plan is to write some utility code like this ...
from substance.models import Substance
def
write_substance_to_production(subst):
prd_subst, create =
Substance.objects.using('production').get_or_create(
name=subst.name,
)
if create:
pass
# copy all subst attributes except id to prd_subst
Q2. Is this a reasonable approach?
Thanks for any hints
Mike
--
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/ee0a7b26-3330-60e2-2ad1-9ef2baa6ba40%40bristle.com
<https://groups.google.com/d/msgid/django-users/ee0a7b26-3330-60e2-2ad1-9ef2baa6ba40%40bristle.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/c4244639-0eb6-16ee-f60d-5029919a50fe%40bristle.com.
For more options, visit https://groups.google.com/d/optout.
|
