so the original code given for login in application.py had rows = db.execute("SELECT ...) and then session["user_id"] = rows[0]["id"]

and the explanation said that that db.execute returns a key which in this case is called rows.

Now for register, then, we just have db.execute("INSERT...) and do we need session["user_id"] = ...and if so how do we get it? Not clear on the rows = db.execute...meaning and have tried to search for an answer..

I have to say that I set up the table so that there is a user-id which auto increments for each user so do I really need a user_id in register?

1 Answer 1


When a user is registering they do not have a user_id because they are not "in the database" until the user record is inserted.

From the spec:

Finally, notice how login "remembers" that a user is logged in by storing his or her user_id, an INTEGER, in session. That way, any of this file’s routes can check which user, if any, is logged in.

Since session["user_id"] is the indicator that the user is logged in, and according to the register walkthrough, register should log the user in, the answer to "do I really need a user_id in register?" is yes, though maybe not the way the question was intended.

You may find this hint from the spec helpful:

If str is an INSERT, and the table into which data was inserted contains an autoincrementing PRIMARY KEY, then execute returns the value of the newly inserted row’s primary key.

  • Thanks. I read that spec and didn't understand how to access the integer in SESSION and also when I used the statement that was in login i.e. session["user_id"] = rows[0]["id"] I got an error message saying int cannot have an index..therefore, session being an INTEGER cannot have an argument is what I conclude from that error message. So I am having difficulty understanding the statement session["user_id"] if session is an INTEGER.
    – cfdphd
    Commented Feb 21, 2017 at 16:51
  • session is not an INTEGER, user_id is. Without context, I cannot comment on the error. There's two operands in the sentence, so is it possible the complaint is about rows[0]["id"]? If session["user_id"] works in (the supplied) login and not in register, is it possible you have a "shadow" variable, ie have redefined it someway in register? All context-free comments. Commented Feb 21, 2017 at 17:17
  • So in Zamyla's video on register she has this slide: db.execute failure? result = db.execute(...) and then next line is - if not result: return apology..however when I wrote result = db.execute - result turns out to be an array but if you print it is an integer.. So that's one question and here's the code in login that I am trying to understand: gist.github.com/39c73c5f19c04210cd57fba9234ffa0c
    – cfdphd
    Commented Feb 21, 2017 at 17:49
  • The code I gave you on github was the original source code from pset7..so now what...how can it be wrong?
    – cfdphd
    Commented Feb 21, 2017 at 19:05
  • My apologies. I was reading it as register code. I'll start again. (I'm going to delete the prev comment. ). It executes session["user_id"] = rows[0]["id"] when len(rows) == 1 (ie it has found a valid user), otherwise it returns an apology. Register is a different (and opposite) case in that you need to bail ("apologize") if len(rows) == 1 (ie username already exists) and "continue" if len(rows) == 0. Which means rows is an empty array, so you cannot access rows[0]["id"]. But you can use the result of the insert query. Commented Feb 21, 2017 at 19:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .