Joe Parente and Joey Perrott are doing afternoon sessions with the Web Coding Bootcamp. I’m learning a lot and transcribing my notes down below.
In our first python project, we’re working on a quote database using The Python NDB Datastore API.
As started the day before, the afternoon session continued on with fleshing out the methods associated with the QuoteModel class in our database. The first step was to list all of the behaviors and then write the methods.
In this project, we used both Class and Instance methods.
The instructors emphasized how simple methods are. You describe what they take, what they do, and what they return. In class, we split up into groups to write different methods that will be used in the data base.
I was in the delete group. We broke down the method into parts. Select the quote, confirm delete, put quote in the trash box, and hide quote on display. And we were wrong. The instructors told us to think like a computer. We’re deep into the back-end of the process. We’re at the point of actually deleting something.
The process of deleting a thing in a database. You get the id. In this method, we start out with the id, then find the entity it’s attached to, then delete the key. Apparently, if you delete a key to an entity, you essentially delete the entity.¹
In the making of a method, developers ask themselves, now, how would I break this. In this case, it would be to give a nonexisting ID number. So, we must validate that the id exists in the database. A simple “if not” (I like python, so clean.) will do the trick.
At first we raised a generic exception, but we were advised to make a custom exception, that way when we’re debugging, it will point to the exact problem and we will be better able to handle it. To make a custom exception, create a new class outside of the class (put it with the rest of your exception classes, you’ll probably have a few) and then call it in the method (as seen below).
In the following method, one of the parameters it takes in is **kwargs. It’s kind of a way of saying “stuff.” The important part is the asterisks and by convention, should name it kwargs, but you can name it anything. It just means that it can handle what you throw in.
“You would use *args when you’re not sure how many arguments might be passed to your function, i.e. it allows you pass an arbitrary number of arguments to your function.” — and kwargs are named arguments.
One can tell that one of the instructors wrote this code. There’s really excellent code comments. Each code comment states what the method does, what it takes in and what it returns. As for knowing what expressions to use, that could be found in the NDB Datastore API. Finding what you need takes some time and knowledge about how databases work.
This group’s challenge was to make sure that a person could only upvote a thing once and to remove the vote if the method was called again by the same user (a functionality similar to the “like button” on Facebook). Their solution was to require the username of the user to run the method and then storing that in the list and if that person’s name is already in the list they are taken out of the list.
- My question for the instructor: What do keys, IDs and entities look like in a hierarchical diagram explaining the structure of a database?
Answer: “There is no hierarchy. In a non-relational database everything is flat. Each object has one key that you can use to identify the object or you can query the object by one of its attributes.” -Joe