Day 25

More Django

Today Django got a bit harder because we focused on the Models. Something I should've mentioned in yesterday's post is that Django uses the MVC architecture, just in different names. Views in MVC are the Controllers in Django. And Templates from Django are the Views in MVC. Anyways, moving past that, one of the benefits of Django is that we do not need a MySQL DB; Django provides us with one! We set up the Model files with all of our tables and what we want on them and we migrate the changes. For each project that we start, there's a Django repository that gives us a DB to use. All we have to do is when we make our changes to our Models, we migrate them up to the Django DB and the changes will be set.

Unfortunately for the cohort, for the past 2 weeks, we've been doing roughly the same type of SQL queries to return what we want from the DBs. Django has its own syntax and queries of how to return information. In some ways, it's very straight forward but for newcomers it can be daunting. For example, usually we write "SELECT info, info etc. FROM table" and we populate the result that we want. Django's DB is an API, and as APIs go, it will return a JSON element. Since it's an object, we can't write in the way we have been for traversing through our information. We instead have to look at JSON in an OOP way to access the information (kind of like how we traversed through the Google Maps API to get the information we wanted). 

Another downside of Django's DB is that there are no visual representation of our data. When you have a query like Modelname.objects.get(id=1), it will return back an object. So thankfully, most of the assignments we've done require small bits of data although in the industry this is most definitely not the case since Python is known for being able to process through huge amounts of data quicker than other languages. Mike however, gave us a pretty print file that allows us to visually see what each object's keys and values are which makes things a bit easier.

Relationships between tables are written in the Models.py file and it's a bit different. In MySQL, when you have a many to many relationship, it will automatically populate a joiner table that has the foreign keys of the two tables it is joining. In Django, this is not the case and you write one line of many to many relationship code into ONE of the tables that you want to join. I like a different approach; creating a third table that acts as a joining table and use a foreign key of one to many relationship between the two tables. The assignments today weren't that hard as again, it was a repeat of what we've done before, just writing it in Django. Gonna relax a bit this weekend after the hard work I put it for the Red Belt!