#34884: Half bug/half enhancement : inconsistent behavior of get_or_create()
regarding related attributes cache
-------------------------------------+-------------------------------------
Reporter: Laurent Lyaudet | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: ORM get_or_create | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Laurent Lyaudet):
Hello Tim,
Thanks for your constructive answer.
I did not think about making the created and the non-created model
instances strictly identical.
I had a much simpler goal, my approach was more agile and more bazaar on
this topic.
But I like the cathedral way of thinking.
And it's maybe more appropriate to think about it for a framework where
you have no control on the code using the framework.
This should not be possible to make it so, since the "API"/convention of
get_or_create() is to apply the defaults values (from "defaults" kwarg)
only on creation.
As of now it is not clear yet, in my mind, how hacky a "field taken from a
query_filter" can be processed.
I mean, for example, is it possible to have a field that is a valid
component of a query filter but also has a "setter" hidden in the class
code ?
Can you have :
my_counter = models.IntegerField(...)
my_foreign_key = models.ForeignKey(...)
with some custom class code such that
whenever my_foreign_key is set the field my_counter is incremented.
I would be able to do it with a property but the property would have a
name distinct from "my_foreign_key".
If I can be provocative, someone that do this deserves to debug his code
when he updates his framework ;) XD.
More seriously, almost anything is possible in the code using Django,
and thus it is about direction.
Breaking changes can happen in any framework on major version releases.
I think my goal/direction was reasonable.
I am just trying to correct a cache inconsistency,
whilst having identical instances in both cases seems to be impossible.
In my point of view, the trade-off is positive,
but I'm open to think about it further.
In any case, correcting this cache inconsistency would be a step toward
identical instances in both cases
Can you restrict your goal of identical instances in both cases to
something more "possible" ?
What kind of compatibility problems do you foresee ?
Best regards,
Laurent Lyaudet
--
Ticket URL: <https://code.djangoproject.com/ticket/34884#comment:9>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018bcff109e1-d15b8872-1ca5-4b85-a244-5882de25aaa6-000000%40eu-central-1.amazonses.com.
