search

manjurulhoque / django-job-portal

Job portal application using Django
MIT License
559 stars 243 forks source link

should user be deleted when job is deleted? #1

Closed kkarpieszuk closed 5 years ago

kkarpieszuk commented 5 years ago

Hello

I am new to Django, but I am also creating my own job board in Django, so that's why I looked into your code :) Please consider this "issue" not as a real issue submission but more like a question to probably more experienced Django dev.

in django-job-portal/jobsapp/models.py you have for example:

class Job(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)

does it really should look like it looks? AFAIK it means "when job is being deleted, deleted the user who submitted the job as well". Am I correct?

If so, do you really think it should be like that? Why the user should be deleted? What if one user submitted more than one job offer? Then if you delete one job, the user will be deleted and then other his jobs will be orphaned, right?

kkarpieszuk commented 5 years ago

or this code means "if an user is deleted, then delete all his jobs"? in which direction this on_delete actually works? (Like I said, I am new, so this is why I am asking :) )

guzmud commented 5 years ago

Hi you, just going through, but know that Django is as much documented as Python, which is a great news you know ;)

Just for pointers:

So, "When an object referenced by a ForeignKey is deleted,"+"Django emulates the behavior of the SQL constraint ON DELETE CASCADE and also deletes the object containing the ForeignKey.". Hence, if the User is deleted, the Job is deleted also.

If the user variable is related to the person posting the job, it may make sense that if the "job offerer" gets down, the job goes down with him/her too. Check the Applicant just after Job in the models file you provided, it's the casual "extend a User class"-pattern (I let you read the awesome https://simpleisbetterthancomplex.com/tutorial/2016/07/22/how-to-extend-django-user-model.html for even more pointers, this guy is gold): if the root dies, the extension dies.

So the real question is: what the hell is this user in the Job class?

I do agree that design wise, a Job should dependent on a source (let's call him the offerer). The source may or may not be a person (you are a company, you can have a single shared account but also multiple individual ones), so this "source" should be a class, that may regroup various users. But that's already heavy lifting regarding db design and all, I think this Job class is just a starting point, be patient :)

kkarpieszuk commented 5 years ago

ok, thanks. Now I understand. So in this case it means like in my second comment: "if an user is deleted, then delete all his jobs"