On 01.12-07:59, Fergus wrote:
[ ... ]
> > bit worrying that you consider the traceback to be 'gumph' ...
>
> Gumph in the sense that it didn't seem awfully relevant in this case,
> as the exception was reasonably self-explanatory. I'm very grateful
> for Python's stack trace in other circumstances, though I've found
> that there are cases where Django magic seems to make the errors and
> the stack more confusing than I think they ought be.
i'm sure you're right but, as you know, it's very difficult for
external parties (i.e. the list) to have faith in that ... generally
better to include such things ... at least in my opinion.
... and that's what counts ! ;-)
[ ... ]
> > there are a couple of ways to munge the logic to make it work but i'm
> > sure you'll figure out what's best for your own scenario.
>
> My just-tried hack involves dumping the values of the Person object
> into the new User too. I'm surprised there isn't a more clean and
> correct way of doing it though, given that I'm probably going to cry
> any time I want to create a "created" field in the User table!
i'd suggest the 'correct' way to transform an object is to create
the relevant functions within one or t'other. for example, defining
an object instantiation function for 'User' that takes a 'Person'
object as a constructing argument, or depending on your "world view"
perhaps a 'make_me_user' function for 'Person' but as you have pointed
out above, there's a number of ways to skin the cat.
ps: no idea where the 'created' field is coming from, i've not seen
it before
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
