OK.
One work around could be to fire the signal manually just after you
set/delete the value? I have not checked it yet :P
Do one thing, implement pre_delete and post_delete signals and check the
values of instance, sender and using. It might give you more information
about what is happening.
On Thursday, March 14, 2019 at 4:22:15 PM UTC+1, Chetan Ganji wrote:
>
> Why do you need to do any calculations in the model code?
>
> I would do any calculations in the views and store them using models. That
> will remove the getters and setters from model.
> Everything should work fine then
That approach is not working for the original poster. So I gave him a
solution that solves the problem.
I meant, its my opinion to keep models slim and write utils to make the
controllers slim.
You don't have to follow it ;-) Follow what makes sense to you. I prefer
it that way.
Regards,
Chetan
There is nothing wrong with having logic in models.
This is the principle of object orientation - encapsulating methods and
properties in a class definition to group related behaviours and attributes
of a specified type of entity.
See the section titled "Make ‘em Fat" here:
https://django-best-pr
Why do you need to do any calculations in the model code?
I would do any calculations in the views and store them using models. That
will remove the getters and setters from model.
Everything should work fine then.
Hope it helps.
Regards,
Chetan Ganji
+91-900-483-4183
ganji.che...@gmail.com
htt
Hello,
I have set up this nice model:
class CustomGroup(models.Model):
name = models.CharField(max_length=255)
_parent = models.ForeignKey(
"self", on_delete=models.CASCADE, null=True,
related_name="descendants", db_column="parent"
)
_depth = models.IntegerField(default=1
6 matches
Mail list logo
