Django DO_NOTHING clause

Using Django Using the ORM
1

Over the past few months I’ve been porting to Django+Bootstrap a web application originally written for PHP+(huge lot of)HTML tags. The new application, when ready, validated, etc, will be put online directly on existing mySQL tables, swapping out the previous one.

Several of my tables have FK relationships as: (lines extracted with SHOW CREATE TABLE emails);

  `member_mail` varchar(100) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL,
  CONSTRAINT `MadeOnAug05` FOREIGN KEY (`member_mail`) REFERENCES `user` (`mail`) ON UPDATE CASCADE,

and the meaning of this is, if field mail in table user is changed to something else, the mySQL daemon will automagically propagate the change to field member_mail in table emails. This feature works, and is of extreme utility.

When I run manage.py inspectdb it created a class containing:

    member_mail = models.ForeignKey('User', models.DO_NOTHING, db_column=‘member_mail’, to_field='mail')

which seems to imply that django will NOT do the said mail change propagation, and I got worried because django documentation clears that although they seem to implement an on_delete cascade (doc wording here very poor) they offer no on_update cascade, and internet searches confirm this.

But, is this a worry at all?

The feature that I need, and uncountable database developers too, is triggered in the database itself, in the schema description: if Django changes field mail in table user how can the database daemon ignore the change, and DO_NOTHING instead?

My guess is, the limitation that I worry about applies only to tables created by django itself, not to others that already exist; but I am not sure.

Thank you for any insight!

2

Sorry for answering myself, I do it in case somebody in the future hits this same question.
From experimentation: running manage.py shell I changed one record in the source table with:

myRecord=User.objects.filter(uid=1499).get()
myRecord.mail='somethingelse@yahoo.com'
myRecord.save()

after which I checked with the mySQL CLI that all records in the object table had changed to ‘somethingelse@yahoo.com’ as required; but looking from the django side I discovered that I had to do this in the manage.py shell:

objRecord=emails.objects.filter(shift_id=85944).get() #get one of the changed records
objRecord.member_mail.mail # a 2-step process, printed 'somethingelse@yahoo.com'

So, member_email is not a value, but some kind of link to the source table. 
With this proviso, all works well. Thank you with your patience, this was a useless post
3

Can you do makemigrations and migrate and then try again and tell me the results?

4

Yes, of course, here is my ride n.1 (for what you ask, go to n.3 below):

  1. Removed the FK constraint from table emails using mySQL CLI:
ALTER TABLE emails DROP FOREIGN KEY MadeOnAug05;

and checked that changes made to field mail in table user (always using the mySQL CLI) do not propagate anymore to field member_mail in table emails.

  1. Run ```manage.py inspectdb emails`` and previous line
member_mail = models.ForeignKey('User', models.DO_NOTHING, db_column=‘member_mail’, to_field='mail')

changed to

member_mail = models.CharField(max_length=100,db_collation='utf8mb3_general_ci')

  1. edit class in models.py to reflect this change, and redo makemigrations and migrate:
    (django_venv) myprompt>python3 manage.py makemigrations
    No changes detected
    (django_venv) myprompt>python3 manage.py migrate
    Operations to perform:
    Apply all migrations: admin, auth, b2mmsdb, contenttypes, sessions
    Running migrations:
    No migrations to apply.
    (django_venv) mypromt>

  2. verified that running manage.py shell the propagation capability is lost also from the django side

  3. but now my database application is shot! So I do

alter table emails add foreign key `MadeOnAug05` (`member_mail`) REFERENCES `user` (`mail`) ON UPDATE CASCADE;

and I checked that propagation capability is recovered, at least in CLI. What about django?

  1. I re-run ```manage.py inspectdb emails` and I obtain a class with a line like:
member_mail = models.ForeignKey('User', models.DO_NOTHING, db_column=‘member_mail’)

and now I remember: to get this propagation to work in django I had to add to_field='mail’ as a final parameter, django simply could not read, or understand it, from the mySQL schema.

Whenever I have time I will try Run n.2: define a new table from the django side, add to it an FK constraint from the mySQL side, and see if the creature works. I expect yes.

In conclusion (you might disagree with me, and rightly too):
A) django is not a database, but an interface to many types of DBs.
B) “Propagation” is a database property: some have it, some have it not.
C) django (in 5.0) ignores that mySQL has it, but at least offers me a way to generate a working class. (If only Karl Marx had known!)

Thank you for reading!