This week’s task is to work on a project plan document, which is a very thorough breakdown of the project from all angles (architecture, tools, UI/UX, timeline, task assignments). There’s a lot to consider when putting these commitments down on paper, and one of the major considerations for our website is the tech stack that we will be using. Python is a common-ground language across the team, so we decided to build the site using Django, a popular Python web framework that offers a customizable full stack solution. Django is a new for all of us, and it will be a nice change of pace to learn something together, compared to the many times I’ve learned alone. Of the many appealing aspects of Django, one of the features that made it a top web framework contender is it’s default object-relational mapping layer or ORM for short.

My newbie understanding of ORM is that it is a programming technique for converting data between different types: data stored in a database’s tables and data represented as objects in the application code. Because ORM is a layer of abstraction on top of the database calls, the application developer can interact with the database in the application’s programming language (i.e. Python). If I want to change the first name of a person, there is no need to write SQL and pass it through to the database. I can just do that in the application code. i.e. If I have a person, “p”:

p = Person(first_name='Jane', last_name='Smith')
p.save()

then I can change the last name like so:

p.last_name='Steele'

“Neat!” “And confusing.” “Is there even a database?” were some of the reactions during our team discussion. I take the fact that the last question even surfaced in our conversation as an indication of how much an ORM can really abstract away the concept of a database. And yes, there is most definitely a database. It is just that we can (hopefully) do less in the database and do more in the application code.

But, is this really a good thing? Good meaning seamless? And bug-less?

Being a cautious person with a questioning mind, I’m both excited to use Python to interact with the database and I’m wary that everything will be “all right back there”, in the DB. How can we be sure that the objects are truly converted properly to rows in the database? Will the related tables update automatically, if a change were made to an object? How can we check that all the constraints we want are in place? How does the ORM account for any subtle differences between the Object Oriented Programming paradigm and the relational model (assuming that a relational database is being used)? These are the initial questions that I have in my mind.

Another concern is with moving what seems to be logic that should live in the database into the application code. How will that affect performance (initially and when we have ten million users after growing 6x)? Or is that the least of my concerns? I have a lot of concerns.

Still, the prospect of writing zero (or at least less) SQL and writing Python, instead, is so very novel, with a huge amount attraction, that I feel it needs exploring. I want to see what the hiccups are, if any, once we get rolling, and how much of a time saver (or maybe a time sink) using Django’s ORM is. I want to see how closely the tables that Django creates matches the ERD that will be submitted in the project plan. I want to try it out and see it in action. I have a lot of wants.

So, with many concerns and many wants, I am excited to start building out our site with Django’s ORM, the current shiny new tech on my radar!