4 ms·

The feature I like the most from this release is by far the swappable User model. Needing an extra table and performing JOINs between the User and my profile ta

The feature I like the most from this release is by far the swappable User model. Needing an extra table and performing JOINs between the User and my profile table have really been a pain. I also like that some effort has been made to update the tutorial, when I started back in 1.2 I recall the tutorial to be quite confusing and didn't know where to go after I finished it. Thanks all involved.

kmfrk 14y ago
It's going to be great to watch those database query numbers drop. :)
codegeek 14y ago
Seems like you read my mind and wrote verbatim. When I started learning web app dev, I started looking at Django (1.2 at the time) and working with User and the user profile and connecting the dots b/w them was a major PITA. Even though I got a workable solution as a side project, that was my last Django project ever. <Now a happy Flask user just as peripheral info>
CoffeeDregs 14y ago
That was what attracted me, too, as I was starting a new project yesterday, but it turned out that the User model stuff is not as straightforward as I expected. In particular, a number of external applications/libraries have hard-coded references to auth.User, so those need to be patched. So I'm using Django 1.5, but I'm using the old User->Profile setup, but I'm storing relatively little on the Profile. EDIT: I've not found User->Profile to be much of an issue. I only store extra data in the Profile and don't have ForeignKeys against it, so I don't actually use the Profile that often.
- kmfrk 14y ago
  I imagine there'll be somewhat of a database migration hurdle going from the profile configuration to auth.User, though. That seems like an incentive to use the format at one's earliest convenience.
  - StavrosK 14y ago
    Yeah, it is a bit weird. It took me around a day to migrate everything.
- pretoriusB 14y ago
  >In particular, a number of external applications/libraries have hard-coded references to auth.User, so those need to be patched. On that front, if I'm using a full blown framework (like Django or Rails) I try not to use any third party plugins for it. Third party libraries (ie. framework agnostic), yes, but not plugins. I find that this is a sane middle ground between: a) doing it yourself from scratch (maybe using a minimal base like Flask/Sinatra) and b) adding the kitchen-sink of variable quality and volatile third party plugins, that are "here today, gone tomorrow". This way you know you're building in a stable base that is gonna be there tomorrow (at least, most of it), that is, the framework, and you also get to build and know intimately the rest of the dependencies you might need.
bobmyers 14y ago
Besides the joins it is great to be able to add custom methods to the user model. For instance, to integrate mysite with django social auth, I can add a method to the user model itself to add the auth id. Which is more natural `user.add_auth_id(provider, uid)`. Instead of calling UserSocialAuth.create_social_auth(user, provider, uid)

kmfrk 14y ago

It's going to be great to watch those database query numbers drop. :)

codegeek 14y ago

Seems like you read my mind and wrote verbatim. When I started learning web app dev, I started looking at Django (1.2 at the time) and working with User and the user profile and connecting the dots b/w them was a major PITA. Even though I got a workable solution as a side project, that was my last Django project ever. <Now a happy Flask user just as peripheral info>

CoffeeDregs 14y ago

That was what attracted me, too, as I was starting a new project yesterday, but it turned out that the User model stuff is not as straightforward as I expected. In particular, a number of external applications/libraries have hard-coded references to auth.User, so those need to be patched. So I'm using Django 1.5, but I'm using the old User->Profile setup, but I'm storing relatively little on the Profile. EDIT: I've not found User->Profile to be much of an issue. I only store extra data in the Profile and don't have ForeignKeys against it, so I don't actually use the Profile that often.

kmfrk 14y ago
I imagine there'll be somewhat of a database migration hurdle going from the profile configuration to auth.User, though. That seems like an incentive to use the format at one's earliest convenience.
- StavrosK 14y ago
  Yeah, it is a bit weird. It took me around a day to migrate everything.
pretoriusB 14y ago
>In particular, a number of external applications/libraries have hard-coded references to auth.User, so those need to be patched. On that front, if I'm using a full blown framework (like Django or Rails) I try not to use any third party plugins for it. Third party libraries (ie. framework agnostic), yes, but not plugins. I find that this is a sane middle ground between: a) doing it yourself from scratch (maybe using a minimal base like Flask/Sinatra) and b) adding the kitchen-sink of variable quality and volatile third party plugins, that are "here today, gone tomorrow". This way you know you're building in a stable base that is gonna be there tomorrow (at least, most of it), that is, the framework, and you also get to build and know intimately the rest of the dependencies you might need.

bobmyers 14y ago

Besides the joins it is great to be able to add custom methods to the user model. For instance, to integrate mysite with django social auth, I can add a method to the user model itself to add the auth id. Which is more natural `user.add_auth_id(provider, uid)`. Instead of calling UserSocialAuth.create_social_auth(user, provider, uid)