Re: 1.11: Value error on related user name during save of user model

On Tue, Aug 22, 2017 at 12:31 PM, Axel Rau <Axel.Rau@chaos1.de> wrote:

Thanks for taking the time to write such an extensive answer.

Thanks. I should really sleep more...

 

 

Some background info:

This is a realtime operational database, for which I try to create a GUI with Django.

The DB is fully normalized and multi-client.

I'll take your word that it's normalized, but I still think conceptually that the username field is in the wrong spot and IMO is the primary cause of this entire conversation. ;-)

As always, there may be a deeper context for the design choice outside the scope of this thread. It probably isn't worth the time to debate because what you are trying to do is supported AFAICT.

 

To reduce the complexity, I have created a concept for shortcuts of model instances, which are used in list views or FK form fields.

Each model has a __str__() method which returns such a shortcut (like the above Mailbox) for an instance.

There are other concepts like

  Model forms just to display data, or, 

Why use a form simply to display data? I'm assuming just for the form.as_table type shortcuts?

 

  For the multi-client part, the PK of the current user is kept in the session along with some Q-expressions to qualify account dependent queries.

Assuming you are referring to the PK of the Mailbox instance containing the username. If you make use of request.user or {{ user }} in the templates, you can access the PK of the user by using request.user.localemail_id or {{ user.localemail_id }}, rather than keeping track of stuff in the session (which the request middleware is already doing assuming you are using it). Might be easier than trying to manage the session data. It's a fun trick that Django doesn't make obvious:

https://docs.djangoproject.com/en/1.11/ref/models/querysets/#values

See the "A few subtleties that are worth mentioning:" section.

As a bonus, if you only need the PK of the related Mailbox object, using the user.localemail_id will only return the PK value, and will not perform an SQL lookup to return the entire Mailbox object just to retrieve the PK like user.localemail.pk would. Comes in handy when trying to minimize queries.

 

My current problem with 1.11 is a model form for Account, which contains a FK field referencing Mailbox in which the above shortcut is displayed as a pop up (forms logic treats remote instance as text).

I changed something else in the form and tried to save with the Mailbox field unchanged.

It seems that forms logic does no longer manage to get the instance from its text representation.

I suppose that is the more succinct way to explain what I was trying to say. As I mentioned, if the same code is working under 1.9, check the release notes for 1.10 and 1.11 to make sure that they haven't deprecated a feature you may have been taking advantage of. I "think" that jumping from 1.9 to 1.11 would skip the deprecation warnings shown in 1.10, and fully drop those features in 1.11. It's hard to tell any more with the new semantic versioning that Django is moving to. The docs have been updated to match the new intended SemVer scheme, but are clear as mud as to how older versions were treated.

 

When I access a model instance, AFAIK my context determines the data type I get (string or model instance).

Is this correct?

If this was working under 1.9 (I'd be surprised if it was), then I would file this as a backward-incompatibility bug with the bug tracker. It's possible that 1.9 did do the type/field conversion using some black magic, but with the information in your model, I don't know how it could have made that determination. 

I have just verified: It still works with 1.9. (-;

If nothing shows in the release notes, I'd recommend a bug report to have the devs take a closer look. 

From a design perspective, the relation you presented seems backwards to me. I would think the Account model would hold the canonical username, and Mailbox would have the FK back to the Account. That design would not require the use of a username field as an FK, simplifying everything (authentication, forms, views, etc.). Your current design would implement excessive SQL JOIN's to pull relatively simple data on every request. 

Or, I could be completely wrong. :-D

Perhaps, I should publish the project at github (it's OSS anyway), to get more advice?

It might help, but I wouldn't bother with the effort unless you were either already planning to do so, or someone asks specifically. I don't have time to read my code, let alone yours. ;-)

--
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+unsubscribe@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/CA%2Be%2BciV3rGPy3jeuSAg75O4KPkSky71WwOYNxv7X%2BH%3DxCZKT3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.