multiple databases - two questions

[Mike Dewhirst]

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

[Mike Dewhirst]

(this one might be easier to read)

[Fred Stluka]

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.

See:
- https://docs.djangoproject.com/en/dev/topics/db/multi-db/#topics-db-multi-db-routing

--Fred

---

Fred Stluka -- mailto:fr...@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.

---

[Mike Dewhirst]

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:fr...@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.

> ------------------------------------------------------------------------

> --
> 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...@googlegroups.com
> <mailto:django-users...@googlegroups.com>.
> To post to this group, send email to django...@googlegroups.com
> <mailto:django...@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.

[Fred Stluka]

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.

--Fred

---

Fred Stluka -- mailto:fr...@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.