From: Edward Z. Yang Date: Sat, 14 Feb 2009 00:04:06 +0000 (-0500) Subject: Add schema comments X-Git-Url: https://sipb.mit.edu/gitweb.cgi/wiki.git/commitdiff_plain/0f7c2d6d24694c24f5c5c6272b224234e8003ad9?hp=eac1381a6d6632e3cbec5498e7755d6318e2fda1;ds=sidebyside Add schema comments --- diff --git a/projects/clockworks.mdwn b/projects/clockworks.mdwn index 9854018..ef24bc2 100644 --- a/projects/clockworks.mdwn +++ b/projects/clockworks.mdwn @@ -29,7 +29,7 @@ What do people not like about Doodle? * [Configure](http://docs.turbogears.org/1.0/Configuration?action=show&redirect=1.0%2FGettingStarted%2FConfiguration) the default TurboGears scaffolding * Work through the [TurboGears tutorial](http://docs.turbogears.org/1.0/Wiki20/Page1) (the tutorial seems to focus on SQLObject, which is not necessarily the best thing. Maybe someone can find some better docs?) -* Setup database configuration and installer (an auxiliary issue is the presence of an installer for people). (**ezyang**) +* Setup database configuration and installer (an auxiliary issue is the presence of an installer for people). (**ezyang**) * Learn SQLAlchemy (**ezyang**) * Make sure the default scaffolding works on Scripts (this includes running TurboGears as CGI). Any work done here should be considered for a TurboGears auto-installer, the equivalent of tgsetup) (**ezyang**) * Write a .gitignore file for generated/not versionable items @@ -38,6 +38,8 @@ What do people not like about Doodle? * Setup a zephyrbot that watches the repository * Learn [Widgets](http://docs.turbogears.org/1.0/Widgets) (we'll be using them for all of the forms in this website) * Polish up and get SSL authentication working with TurboGears Identity (the two should be integrated together in a sane manner.) +* Write model classes for all of our tables +* Write controllers for each of the pages ### Architecture @@ -61,7 +63,15 @@ Other ideas: ### Schema -To be transferred from the whiteboard +You can view the database schema in *model.py*. Some notable features: + +* All `user.user_id` foreign keys are paired with an `anon_name` field. If user_id is null, then the associated entity was posted by an anonymous user, and `anon_name` contains the name they submitted for themselves +* The current `time_slots` table uses `DateTime` and `Interval` to define events. We should consider whether or not 15 minute timeslices will be the native representation in the database, or simply a simpler model for the interface +* `length` is likely common through all possible times for an event, so it's stored in both `time_slots` and `event` +* `events.timezone` represents the timezone that the event is occurring in, so we can give user-friendly times. If this field is null, then the creator's `user.timezone` field is used (if that is also null, we should probably use EST) +* `key` and `admin_key` in `event` refer to random values that will compose the URLs for events. +* For full backwards compatibility, `hidden` and `extended` are stored as boolean attributes (the former refers to hiding the responses of users, the latter refers to allowing Yes/No/IfNeedBe responses). We may want to consider an alternate model for these properties +* The schema is not very generalized. Certain parts should definitely be generalized, but let's try to avoid the architecture astronaut syndrome. ### Page Inventory