Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You can copy fields over if you like, and dual-update them as you have in the above, but that's not the purpose of the profile. It's supposed to handle fields not in the original auth.User, since you shouldn't need to edit that model directly. You mentioned "extending User" above - you aren't actually inheriting from auth.User, are you? I highly don't recommend that.</p> <p>Update:</p> <p>See <a href="http://birdhouse.org/blog/2009/06/27/django-profiles/" rel="nofollow noreferrer">this reference material</a>. It is using the same syntax as you to do user-updating inside the profile. </p> <p>Update 2:</p> <p>The example is for <strong>edit profile</strong>, not create profile. Looking at the code in profile.views.create_profile:</p> <pre><code>if request.method == 'POST': form = form_class(data=request.POST, files=request.FILES) if form.is_valid(): profile_obj = form.save(commit=False) profile_obj.user = request.user profile_obj.save() </code></pre> <p>So it saves the form <em>first</em>, then sets <strong>user</strong>, then saves the profile.</p> <p>That means you can't set the user values in the form.save, you need to do it in the profile's model.save:</p> <pre><code># in sumaConnectUser: from django.db.models.base import ObjectDoesNotExist class sumaConnectUser(models.Model): ... def save( self, *args, **kwargs ): s = super(sumaConnectUser,self).save( *args, **kwargs ) try: u = s.user u.first_name = self.first_name u.last_name = self.last_name u.save() except ObjectDoesNotExist: pass return s </code></pre> <p>Basically, by looking at the code in profile.views.create_profile, we are <em>positive</em> that it <em>eventually</em> calls save on the profile <em>after</em> it has set <code>user</code>. It might not be the first time, so we need to trap that case and forget about it. Because eventually, it'll get called and trigger our save-to-user code. The upshot is that no matter what forms you have in the future for this user-profile, it'll always save back to the underlying user.</p>
    singulars
    1. This table or related slice is empty.
    1. PODjango-profiles custom create/edit modelForm not saving properly
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USeruciform
    1. USeruciform
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PODjango-profiles custom create/edit modelForm not saving properly
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COI am not inhereting from auth.User, but instead extending it through the ForeignKey field in the profile model. I know you said I shouldn't be dual-updating anything, but it doesn't seem to me like I am. I mean, all I want is for the user to be able to edit the first_name and last_name attributes of the auth.User model. Therefore I include the two fields in the form. Then I assign them to the appropriate fields in the User and save it before saving the whole profile. When you say try using super.save, do you literally mean putting "super.save()" as the first line in the save function?
      singulars
      1. PO
      1. USdpetters
    2. COsorry, was writing shorthand. i meant your super call as written. nothing wrong with dup-ing fields in this particular case, IMHO, otherwise you need to have two forms and/or edit auth.User.
      singulars
      1. PO
      1. USeruciform
    3. COSo I tried putting "profile = super(ProfileForm, self).save(*args, **kwargs)" at the very top and then "return profile" at the very bottom of the function, but I still get a "DoesNotExist at /profiles/create" error at the "u = self.instance.user" line. Not even self.instance exists. Does this mean I need to instantiate the profile the first time around?
      singulars
      1. PO
      1. USdpetters
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload