On 9/17/07, Jorge Godoy <[EMAIL PROTECTED]> wrote:
>
>
> On Monday 17 September 2007 15:28:00 Kevin Cole wrote:
> > One thing I've learned is that SQLAlchemy wants primary keys for the
> > entities that reference the views. Since many of my views don't have
> any
> > single unique column, and I'm not particularly seeing the need (in this
> > case), is it reasonable to just [CREATE SEQUENCE whatever CYCLE] in
> > PostgreSQL and then in the view, issue a [SELECT nextval('whatever'),
> ...]
> > to get a unique value that can satisfy SQLAlchemy's need?
>
> I wouldn't go that route. I prefer concatenating the PKs of the records
> in a
> new column to form the primary key. I usually have, on these cases, an
> idType of 'str'. Another alternative is retrieving one of the PKs alone
> is
> it isn't repeated.
>
> The bigger problem with using the sequence is if you want to operate on
> one of
> the records returned by your view: you won't be able to find out which
> record
> you should deal with.
The message I'm getting is that syntactically, I'm okay, but perhaps unwise.
Well, more explicitly... The situation is this: I have a table of
questions, which contains a primary key ID for each question as well as the
question's text, the question's position, and the question's type. I have a
table of respondents, and two different tables of responses. Each
respondent has a primary key ID, and each response also has a primary key
ID. (There's also another table that breaks the survey down into sections
and provides informational / instructional text for each section. Each entry
in this table also has a primary key.)
So, my thinking was to first have a page listing respondents. Click on a
respondent (or choose from a pull-down list, or some such), and it brings up
a page of questions, with responses of the respondent you chose. Click on a
question at that point, and it brings up an edit screen which allows you to
change the responses to that question by that respondent , offering choices
from yet another table that offers only valid response choices for that
question.
Since that edit page is the only point at which data may be changed, I'll
have the primary key for the respondent, the primary key for the question,
the primary keys for the responses, and the primary keys for the possible
choices. So, I will know which record(s) to deal with at that point. But
in some of the screens leading up to that point, I'd need to unnecessarily
(in my uneducated opinion) clutter up the view with multiple columns that I
don't really intend to use. However, I'll reconsider adding more columns
in...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
