In app.py the (badly named) summary() method (should be get_buggy_json() maybe?) uses the dbatabase column names to produce the JSON — so these must match the JSON names in the specs. The tech notes warn about deviating from this but don't explain why — it's probably worth adding a warning inside init_db.py too, because this problem arises when the student edits that file. (Unless they are changing the db columns in some other way, which is less likely).
Note that it is OK, but unwise, for names in the python to differ (e.g., vars and form names): the tech notes tell students not to use their own names
tech-notes/add-input-to-form#why-the-name-you-use-is-critically-important
(ahem, "critically important") but could also mention that the database name is being used to generate the JSON, as that's not explicit in the code if you don't understand the SQL.
In
app.pythe (badly named)summary()method (should beget_buggy_json()maybe?) uses the dbatabase column names to produce the JSON — so these must match the JSON names in the specs. The tech notes warn about deviating from this but don't explain why — it's probably worth adding a warning insideinit_db.pytoo, because this problem arises when the student edits that file. (Unless they are changing the db columns in some other way, which is less likely).Note that it is OK, but unwise, for names in the python to differ (e.g., vars and form names): the tech notes tell students not to use their own names
tech-notes/add-input-to-form#why-the-name-you-use-is-critically-important(ahem, "critically important") but could also mention that the database name is being used to generate the JSON, as that's not explicit in the code if you don't understand the SQL.