Model2

[KarahanS]

Within the model2 branch, following changes have been made:

• Added __str__(self) functions to view the current entities in the database with customized strings in the admin panel.
• Added description field to the Tag model.
• Added commented_on field to the Comment model in order to map each Comment object to an art item. Removed comments field from ArtItem model.
• Installed Pillow package to deal with images. Updated requirements.txt accordingly.
• Added profile_image and art_item fields to User and ArtItem respectively. Added path of the "media/" to the settings.py file. When one uploads a profile image, it is saved in Practice App/media/avatar/<username>_<filename>. When one uploads an art item image, it is saved in Practice App/media/artitem/<artitem_title>_<filename>
• Removed follows and followed_by fields from User. After making some research on that, I find that best practice is to create a new model for follow operation as described here.
  • If a user attempts to follow himself, it returns an integrity error (The one responsible for the API must suppress this error and return a JSON object accordingly.)
  • If a user attempts to follow a user he is already following, then it gives a simple error in the form of "Follow with this From user and To user already exists.".

[KarahanS]

• To store the images, I believe these formats are more appropriate:

  • Practice App/media/<avatar>/<user_id>_<filename>.
  • Practice App/media/<avatar>/<artitem_id>_<filename>.

  However, I couldn't use them because of this problem:
  While we are creating a user, id of that user is actually None. id field is assigned after the creation of the user. Therefore if we try to upload an image with the name "profilepicture" during the creation, it is saved as "media/avatar/None_profilepicture", which is not pleasant. For now, I've used other fields but we have to solve this somehow. I used "title" for the art item and it's not unique. If we try to upload an image to an art item and there is another art item with the same name and an image with the same filename, then it is replaced - which is not something we want. Should we make title unique?

• Right now there is no limit on the number of images for an art item to be uploaded. We have put a 12-image per art item limit in our requirements. Should we put the same limit?

[BElifb]

• Why would tag need a description ?
• About comment mapping; I searched for ways to represent weak entities through django models but couldn't find a direct correlation. Here it mentions a similar method to what you did, but honestly still feels backwards to me as we are more likely to reach comments through ArtItem than the other way around.
• About the follow fields; I think it was wrong to include both follows and followed_by (original django document suggests to choose one or the other as well). I can't see the potential problem if we just include one, but maybe if you explain the point a bit more we can make a decision (seperate table seems okay too).
• Can't believe we forgot the image field 😆 . I think the problem you mentioned would be solved if we didn't store the images in separate directories for each instance of the classes. (Which seems like the practice as far as I can tell). And for the same name case I belive django addes a suffix unless storage=OverwriteStorage() is set.
• Also don't think the stored image file name needs to reflect the corresponding user or item as we have an easy way of reaching it through the image field of the class.
• Lastly I think 1 image per ArtItem suffices for the demonstrational purposes of the practice app.

[BElifb]

• I am planning on updating the image fields accordingly, just wanted to give a heads up to avoid further simultaneous edits. Or would you prefer to do it @KarahanS ?

[KarahanS]

Why would tag need a description ?

• It seemed very "void" while creating some tags. While I was testing, I have created a tag like "Marine Art" and I wanted to add a brief description about that. A nice example of this can be found in Stackoverflow tags. For example, here you can find the questions under the python tag, it also includes a description about the tag. I think there is no harm in adding descriptions to tags.

About comment mapping; I searched for ways to represent weak entities through django models but couldn't find a direct correlation. Here it mentions a similar method to what you did, but honestly still feels backwards to me as we are more likely to reach comments through ArtItem than the other way around.

• Adding a commented_on field to the Comment enforces Comment objects to be mapped to one and only one ArtItem. Otherwise it was possible to create comments without art items.

About the follow fields; I think it was wrong to include both follows and followed_by (original django document suggests to choose one or the other as well). I can't see the potential problem if we just include one, but maybe if you explain the point a bit more we can make a decision (separate table seems okay too).

• I decided to create a new table after seeing similar examples on that. I think one-field solution with a models.CheckConstraint similar to the one in the code is also ok. I don't know which one to prefer truth be told. You can change it if you want or we can update it if people have problems with this implementation during the API development.

Can't believe we forgot the image field 😆 . I think the problem you mentioned would be solved if we didn't store the images in separate directories for each instance of the classes. (Which seems like the practice as far as I can tell). And for the same name case I belive django addes a suffix unless storage=OverwriteStorage() is set.

• Sorry, couldn't understand what you meant here "in separate directories for each instance of the classes". There is one main directory named "media", then there are two subdirectories "avatar" and "artitem". In that directories, we store the image files in the format given above.
• That's great that Django deals with data deletion due to the conflicts by default.

Also don't think the stored image file name needs to reflect the corresponding user or item as we have an easy way of reaching it through the image field of the class.

• You are right, I just wanted to find a unique way to store each image file so that any collision wouldn't lead to the loss of some image files.

Lastly I think 1 image per ArtItem suffices for the demonstrational purposes of the practice app.

• Agreed. So, how can we enforce that there is only one artitem_image for each art item? Btw, right now that field has blank=True, so it's possible to create an art item without an image. Should we allow it? Btw, if you want to difference between blank=True and null=True: here

I am planning on updating the image fields accordingly, just wanted to give a heads up to avoid further simultaneous edits. Or would you prefer to do it @KarahanS ?

• I'd be grateful if you could update the image fields, have a look at artitem_image field and then merge the pull request. Any other modifications are also welcomed.

[BElifb]

• Updated image field structure.
• Added default images.
• Removed media from .gitignore to keep images.

[KarahanS]

• Reviewed the changes. ImageField paths seem ok.