very nice, thank you. I will look up the book.
On Jun 24, 2:37 pm, Daniel Roseman wrote:
> On Jun 24, 7:01 pm, Sector7B wrote:
>
> > Thanks for the feedback and the link, all good stuff!
> > I looked at what i had written, and I think a better way to ask the
> > question is:
> > What are the me
On Jun 24, 7:01 pm, Sector7B wrote:
> Thanks for the feedback and the link, all good stuff!
> I looked at what i had written, and I think a better way to ask the
> question is:
> What are the mechanics behind providing "choice_set.all()"?
> For example i have a field "choice" so having "_set" (con
Thanks for the feedback and the link, all good stuff!
I looked at what i had written, and I think a better way to ask the
question is:
What are the mechanics behind providing "choice_set.all()"?
For example i have a field "choice" so having "_set" (concatenated) is
that generated when i run syncdb
I'd add to Michael's comment that if you're unhappy with this syntax
(I personally find it a bit odd in some cases), you can customize
exactly what word is used there in your model definition.
If you alter the choice model and add the "related_name" keyword to
the foreign key definition, e.g.:
cl
(Sorry in advance for the brevity and any typos, I am typing this from
my aging Windows Mobile).
It's quite Django-specific actually. If you take a look at
http://docs.djangoproject.com/en/dev/topics/db/queries/ it says,
"Django also creates API accessors for the "other" side of the
relationship
Hi,
In the tutorial 1.
It has this:
# Give the Poll a couple of Choices. The create call constructs a new
# choice object, does the INSERT statement, adds the choice to the set
# of available choices and returns the new Choice object. Django
creates
# a set to hold the "other side" of a ForeignKey
6 matches
Mail list logo
