4 ms·
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.
by 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 agoI 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 agoYeah, 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.