On Sat, 2007-03-24 at 08:47 -0400, Todd O'Bryan wrote: [...] > Let me ask a silly question before I go off and do something radical, > just to make sure I won't hit a brick wall later. > > I'm trying to model every conceivable kind of question in a way that > won't involve changing the database later. To do this, my Question model > has some meta-information and has a OneToMany mapping to a DataBit > model. A DataBit has fields for type and one piece each of textual and > numeric data. If I want a true/false question, it has two DataBit > objects: a bit containing the statement and a bit indicating whether > it's true or false. If I want a fill-in-the-blank question, it has one > DataBit instance for the statement and one for each answer that belongs > in the blanks. For a multiple-choice question, there are several bits: > the question, each possible answer, and a bit saying which answer is > correct.
Okay, I understand what you're trying to achieve here. It looks like it might be a job for Generic relations, since it sounds like you are wanting to relate one model (Question) to an arbitrary other type of model (the answers), differentiating by some "type" string. If you haven't seen them yet, have a look at http://www.djangoproject.com/documentation/models/generic_relations/ . I don't know if this will make your life easier or not, but it sounds like an alternative (or equivalent) to what you are doing. > Obviously, trying to represent these things directly from the database > is a bit of a pain, so I have non-model classes that translate from the > representation in the database to a more natural representation and vice > versa. These classes also create the forms (as in django.newforms) that > I display. > > Could I pickle one of these non-model objects and use the pickled value > in a hidden field to store everything all at once and then get it back > really easily? I've never used pickle, so I'm a little apprehensive that > there are gotchas I don't know about, but, if it works the way it's > advertised, it seems an easy way to dump something into the preview and > then reconstruct it on the way out. Are there any gotchas I should be > aware of before I start? It's a security hole if you just do it the way you described. As you no doubt realise, just because the field is hidden, doesn't mean it's value cannot be changed. So you are going to end up unpickling random data that somebody you don't know or trust has just sent you and that could have unintended side effects. One way to avoid this is to sign the pickled string (e.g. hash the combination of the string with a secret mixed in). Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
