2009-05-14 10 views
1

Wir betreiben Django neben - und teilen eine Datenbank mit - einer bestehenden Anwendung. Und wir wollen eine existierende "Benutzer" -Tabelle verwenden (nicht die von Django), um Benutzerinformationen zu speichern.In Django, wie können Sie die Benutzerklasse ändern, um mit einer anderen db-Tabelle zu arbeiten?

Es sieht so aus, als ob es möglich ist, den Namen der Tabelle, die Django verwendet, in der Meta-Klasse der Benutzerdefinition zu ändern.

Aber wir würden es vorziehen, den Django-Kern selbst nicht zu ändern.

So denken wir, dass wir die Unterklasse der Kern auth.User Klasse wie folgt konnte:

class OurUser(User) : 
    objects = UserManager() 
    class Meta: 
     db_table = u'our_user_table' 

Hier ist das Ziel, keine zusätzlichen Felder der angepassten Benutzerklasse hinzuzufügen. Aber nur um die alternative Tabelle zu verwenden.

Dies schlägt jedoch fehl (wahrscheinlich weil das ORM davon ausgeht, dass die our_user_table einen Fremdschlüssel haben sollte, der auf die ursprüngliche User-Tabelle verweist, was nicht der Fall ist).

Also, ist dies eine sinnvolle Art zu tun, was wir tun wollen? Habe ich einen einfacheren Weg verpasst, um Klassen auf Tabellen zu kartieren? Oder, wenn nicht, kann das funktionieren?

Update:

Ich glaube, ich könnte in der Lage sein, die Veränderung, die ich nur durch „monkey-Patching“ machen will die _meta des Benutzers in einem local_settings.py

User._meta.db_table = 'our_user_table' 

jemand etwas denken kann, was könnte passieren, wenn ich das tue? (Besonders im Zusammenhang mit einer ziemlich typischen Django/Pinax-Anwendung?)

Antwort

6

Sie könnten es nützlich finden, Ihre alte Tabelle als alternative authentication source einzurichten und all diese Probleme zu umgehen.

Eine andere Option ist subclass the user und die Unterklasse muss auf Ihr Benutzermodell zeigen. Überschreiben Sie die Speicherfunktion, um sicherzustellen, dass alles vorhanden ist, um Ihre alten Funktionen zu erhalten.

Ich habe keine dieser beiden selbst gemacht, aber hoffentlich sind sie nützliche Hinweise.

aktualisieren Was ich alternative Authentifizierung in diesem Fall bedeuten, ist ein kleiner Python-Skript, das sagt: „Ja, das ist ein gültiger Benutzername/Passwort“ - es dann eine Instanz des Modells in der Standard Django Tabelle erstellt, Kopien Felder gegenüber der Legacy-Tabelle und gibt den neuen Benutzer an den Aufrufer zurück.

Wenn Sie die beiden Tabellen synchron halten müssen, können Sie sich entscheiden, Ihre alternative Authentifizierung nie einen Standard django Benutzer erstellen und einfach sagen: „Ja, das ist ein gültiges Passwort und Benutzernamen“

+0

+1 Alternative Authentifizierung Quelle. –

+0

Das Einrichten eines Backends, das das tut, was Sie brauchen, ist der Standard und empfohlene Methode, um andere Authentifizierungsquellen mit Django zu verwenden. Das sollte diese Person also tun. Auch eine schnelle Google-Suche stellt ziemlich viele auth Backends in der Wildnis, die als Beispiele verwendet werden können :) –

+0

Danke. Vielleicht war ich nicht klar genug, aber genau das versuchen wir. (Ie. Alternative Authentifizierung und eine Unterklasse von Benutzer verwenden).Das Problem besteht darin, dass das ORM nun durch das Erstellen einer Unterklasse erwartet, dass die benutzerdefinierte Tabelle (unsere Legacy-Tabelle) ein Feld enthält, das ein Fremdschlüssel für die ursprüngliche django-Tabelle auth_user ist. Und es wirft einen Fehler auf, weil das nicht existiert. – interstar

Verwandte Themen