If you find yourself moving from symfony to Django, here’s how you sf_guard_user’s user table to django.contrib.auth user table:
INSERT INTO
auth_user (id, username, password, is_active, last_login, date_joined)
SELECT
id,
username,
CONCAT(algorithm,'$', salt, '$', password),
1,
last_login,
created_at
FROM sf_guard_user;
DROP TABLE sf_guard_user;
Luckily, django uses a similar salting and encryption strategy as symfony, so it’s easy to go back and forth.
Filed under spindrop. |
Tags: django && symfony
I’m picking up a pet project of mine that I was working on a few months back. It’s written in Django and is openID enabled… but I didn’t used django openID and I have no clue why… I wrote my own code.
My best guess is I wrote my own code, just so I could understand it better, and that perhaps django openID wasn’t mature enough or documented well enough.
Whatever the reason, in the future when I take the non obvious route… that I actually document the “why?” This will save me the tedious task of determining if I need to swap out my code and replace it with something that’s more maintained.
In any case, it’s certainly refreshing to tool around with Django some more… it’s a lot more pleasant than the PHP that I’m often subjected to…
Filed under spindrop. |
Tags: openid && projects
