Confused about generic.create_update

> The easiest fix I can think of would be to put a hidden
field in your
> form that holds the id of the current user. This will
put a 'user'
> entry into your form data, which will allow the
create/update generic
> views to submit without error.

I definitely do not want to do this for security reasons.
Just because
it's hidden doesn't mean someone can't write a script to
POST to my
page with any user_id they want. And then I ask, what is the
point of
passing the generic view an object_id? Is there a better way
to
approach this problem? My code isn't set in stone, I'm ready
and
willing to learn to do it the right way. It makes sense in
my head, but
Django isn't following the same logic as I.


> Another option would be to use the 'follow' argument in
the
> create/update generic views: this argument describes
which attributes
> of an object will be represented as field data; if you
list the
> attributes that _are_ present as fields, but exclude
'user', then the
> error should go away. However, this assumes that
UserProfile.user
> is/will be assigned at some other time.

I'm not sure I understand the 'follow' argument. I will look
into it in
the documentation. The UserProfile.user should already be
populated.
Afterall, a user is updating an existing UserProfile.

Thanks for the feedback,
Grant


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

On 9/27/06, gkelly <gkellygmail.com> wrote:
>
> > The easiest fix I can think of would be to put a
hidden field in your
> > form that holds the id of the current user. This
will put a 'user'
> > entry into your form data, which will allow the
create/update generic
> > views to submit without error.
>
> I definitely do not want to do this for security
reasons. Just because
> it's hidden doesn't mean someone can't write a script
to POST to my
> page with any user_id they want. And then I ask, what
is the point of
> passing the generic view an object_id? Is there a
better way to
> approach this problem? My code isn't set in stone, I'm
ready and
> willing to learn to do it the right way. It makes sense
in my head, but
> Django isn't following the same logic as I.

I think I've worked out the problem you are having.

As it stands, each instance of your UserProfile model will
have a
unique 'user' attribute, but it will also have an 'id'
attribute
acting as a primary key. This 'id' attribute will has no
relationship
with the underlying user id (as no relationship is
specified). In
addition, any generic view will expect you to provide a user
id
whenever you submit new values. Hence the 'missing user'
error
message.

It seems like your assumption is that by making the user
attribute
unique=True, it will become the primary key. It doesnt -
that keyword
just makes the attribute unique across the table. You can
have
multiple unique attributes, if you want to.

You have to specify primary_key=True (instead of
unique=True) to make
the attribute a primary key. Once you have done this, the
generic
views should work as you expect - with this definition, you
are
describing the fact that instances of User are linked to
instances of
UserProfile by way of their primary keys, and when you
specify an
object_id you are providing detail to populate the user
field (since
the object_id _is_ the user id).

Yours,
Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

Thanks for looking into this more. What you said makes
sense, and I was
almost on my way to that conclusion. Specifying
primary_key=True is
probably what I need. I'll give it a try.

Thanks,
Grant


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

Can a ForeignKey be a primary key? I'm getting the following
error.

Here is the relevant part of the model:

class UserProfile(models.Model):
    user = models.ForeignKey(User, primary_key=True,
edit_inline=models.STACKED,
num_in_admin=1,min_num_in_admin=1,
max_num_in_admin=1,num_extra_on_change=0)
    ...

$ python manage.py sql profiles
calling execute_manager
BEGIN;
Traceback (most recent call last):
  File "manage.py", line 12, in ?
    execute_manager(settings)
  File
"/usr/local/lib/python2.4/site-packages/Django-0.95-py2
.4.egg/django/core/management.py",
line 1319, in execute_manager
    execute_from_command_line(action_mapping, argv)
  File
"/usr/local/lib/python2.4/site-packages/Django-0.95-py2
.4.egg/django/core/management.py",
line 1286, in execute_from_command_line
    output = action_mapping[action](mod)
  File
"/usr/local/lib/python2.4/site-packages/Django-0.95-py2
.4.egg/django/core/management.py",
line 115, in get_sql_create
   
final_output.extend(_get_many_to_many_sql_for_model(model))
  File
"/usr/local/lib/python2.4/site-packages/Django-0.95-py2
.4.egg/django/core/management.py",
line 233, in _get_many_to_many_sql_for_model
    table_output.append('    %s %s %s %s (%s),' % 
KeyError: 'ForeignKey'


If I remove primary_key=True, then it happily produces the
SQL (with
the default primary key 'id').


Grant


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

On Thu, 2006-09-28 at 17:08 +0000, gkelly wrote:
> Can a ForeignKey be a primary key?

Possibly not.

>  I'm getting the following error.
> 
> Here is the relevant part of the model:
> 
> class UserProfile(models.Model):
>     user = models.ForeignKey(User, primary_key=True,
> edit_inline=models.STACKED,
num_in_admin=1,min_num_in_admin=1,
> max_num_in_admin=1,num_extra_on_change=0)
>     ...

Given the way you are wanting to use this, isn't there only
going to be
one UserProfile per User? If that is the case, a one-to-one
field will
fit your requirements nicely, since it is a primary key by
default (at
the moment, you can't make it *not* be a primary key).

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-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---