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. If I can
get it going it becomes a nice-to-have feature. Plan B is to manually
copy the records and laboriously ensure nothing has been missed. The
actual antithesis of having a computer doing stuff in the first place.
Bit like using liquid paper on the screen instead of backspace.
I'm using Django 1.8.x Admin. I thought I'd add a field called
"Transfer" and if transfer was triggered then I would call a utility
function to transfer the records.
The use case is a database of substances and mixtures of substances. A
mixture happens when multiple substances are linked to another substance
(the mixture) via a through table called Substance_Ingredients each
record of which carries the ingredient proportion. Then there are many
FK relationships between other tables containing different sets of
substance properties as applicable. Some of those are 1:1.
How would it work for entities with a foreign key? Django assumes
foreign keys can't be cross-database since the constraint can't be
enforced.
Agreed. However we don't need to maintain relationships between
databases after the transfer. To help explain, here is the help_text for
the above-mentioned "transfer" field ...
help_text='Select /To the production database/ and click [Save] to
transfer this substance to the production database. Here are the
transfer rules:
1. The exact same Division must exist at the destination
2. This substance must not exist at the destination. A transfer can only
be done once.
3. Visit the production site to verify that the transfer was successful.
4. Recreate the SDS (which is not transferred)
Note that if this is a mixture, its ingredients will also be transferred
unless those ingredients belong to other Divisions/Companies. This means
some mixtures may be incomplete at the destination and thus may require
some rework.'
... which help_text might change if we can add a kwarg, say
db='production' so _saveasnew (in contrib/admin/options.py) can cross
the divide.
In any case, transferred records will necessarily have different ids in
the destination database so all transfers will need to be done using
queries. This is why piggy-backing on [Save as new] beats doing things
either manually or programmatically in my own utility functions.
Your thoughts?
Mike
On Tuesday, November 8, 2016 at 4:29:48 PM UTC-5, Mike Dewhirst wrote:
I'd like to use the [Save as new] infrastructure to transfer
records and
their children to a different database.
Can anyone give me some advice on whether this is a reasonable
project
to attempt? Would it be valuable for anyone else?
My alternative is to build a separate mechanism for my own use.
Which I
have started but I can see it is going to get overly complex.
Thanks
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/7d1bd5c7-cffa-4b4a-bf1b-7dbb1e18f504%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/7d1bd5c7-cffa-4b4a-bf1b-7dbb1e18f504%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/7fdd9d7c-6467-af61-254a-e53341d049dc%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.
