[django]: Models-Klassen mit normalen Attributen ergänzen?

[Silmaril]

Hallo Leute

Ich bin ein neuer in der Django-Welt und habe leider keine Möglichkeit das Folgende zur Zeit auszuprobieren.

Heute habe ich mir die Datenstruktur meines neuen Projektes durch den Kopf gehen lassen. Die Models in models.py zu definieren war einfach. Ich habe zum Beispiel ein Model namens Arbeitgeber.

Code: Alles auswählen

class Arbeitnehmer(models.Model):
    #einige Tabellenfelder
    vorname = models.CharField('Vorname', max_length=50)

Dieses benutze ich, um wichtige (Meta-)Daten über den Arbeitnehmer in die Datenbank zu speichern und den Arbeitnehmer in einem anderen Model mit models.ForeignKey('Arbeitnehmer', Arbeitnehmer) zu referenzieren. So weit so gut.

Jetzt gibt es aber für den Arbeitnehmer auch Daten, die eher temporäre Daten sind. Das heißt die haben nichts in der Datenbank verloren. Außerdem gibt es auch einige Funktionen, die dem Arbeitgeber zugeordnet werden.
Ich als braver Pythoner habe natürlich gelernt, dass da ne Klasse "Arbeitnehmer" das richtige ist, die mit ich mit Attributen und Methoden spicke.

Da kam mir die Idee ob ich das nicht auch einfach im Model hinzufügen kann. Also Attribute, die keine Tabellenfelder sind.
Also etwa so:

Code: Alles auswählen

class Arbeitnehmer(models.Model):
    #einige Tabellenfelder
    vorname = models.CharField('Vorname', max_length=50)
    #und einige normale Attribute
    tmp_projekt = ""
    #und Methoden
    def change_project():
        pass

Hat das dann - wenn es funktioniert - negative Seiteneffekte? Schließlich wird die Model-Klasse ja nicht von object, sonder von models.Model abgeleitet. Kann ich dann in allen Fällen auch so drauf zugreifen, wie auf ein normales Model:

Code: Alles auswählen

a = Arbeitnehmer.objects.filter(id=13)
a.tmp_projekt

Würde das immer einfach so funktionieren?

[Dauerbaustelle]

Ja.

``tmp_projekt`` würde halt nirgends permanent gespeichert werden, d.h. wenn du Zeuch aus der Datenbank holst, haben die entsprechenden Felder eben den Defaultwert.

[Silmaril]

Danke, heißt das nach jedem get() ist das Attribut "leer"?.
Ich muss das daheim mal ausprobieren.

[Dauerbaustelle]

Danke, heißt das nach jedem get() ist das Attribut "leer"?

Jupp, wo soll es denn herkommen? :-)

Vielleicht willst du mal genauer beschreiben, was du vorhast. So allgemeingültig könnte ich ansonsten mal z.B. memcached vorschlagen für Dinge-die-nicht-in-die-Datenbank-gehören.

[Silmaril]

Für die Daten würde auDjangoch Attribute von Objekten reichen. Allerdings will ich meine db-Einträge schon mit den Django-Funktionen ansprechen. Also immer mittels der id.

Wahrscheinlich werd ich die Kröte schlucken und die Daten in die db schreiben.

[Silmaril]

Hallo

So ich habe darüber nachgedacht und jetzt hab ich auch mal Zeit mein Problem genauer zu beschreiben.

Ich möchte für eine bestimmte kleine Firma eine einfache Stempeluhr bauen, mit der jeder Arbeitnehmer seine Arbeitszeiten pro Projekt erfassen kann. Dazu kommen noch Views mit Statistiken.
Ich habe Tabellen namens "Arbeitnehmer", "Projekt" eine "Zeiten" und die entsprechenden Models dazu.

Außerdem habe ich Funktionen, die man dem Arbeitnehmer zuordnen kann und Daten, die aber eigentlich nicht in die Datenbank gehören, da sie nur quasi temporär sind. Und zwar ist das die Projekt-ID, in dem der Arbeitnehmer zur Zeit aktiv ist und die Zeit des "Einstempelns". Diese Daten muss ich nur solange aufheben, bis der Arbeitnehmer wieder ausstempelt oder das Projekt wechselt, weil dann der Zeiteintrag geschrieben wird.

Die Idee, diese temporären Daten einfach als normale Attribute in der Models-Class anzulegen, ist wohl doch nicht so gut, da ich die Tabelleneinträge meistens wohl über Arbeitnehmer.objects.get(pk=42) bekommen möchte und nicht eine Klasseninstanz anlegen möchte auf das ich dann immer zugreifen muss.

Jetzt sehe ich zwei Möglichkeiten:
1.) Ich schreibe die Daten halt doch in die DB. Aber ich möchte die Datenbank schlank halten und vor allem unnötige Zugriffe vermeiden.
2.) Ich lege einfach ne verschachtelte Liste an, die für jeden Arbeitnehmer die zwei Variablen enthält.

gibt es sonst noch gute Möglichkeiten?

[Dauerbaustelle]

Und zwar ist das die Projekt-ID, in dem der Arbeitnehmer zur Zeit aktiv ist und die Zeit des "Einstempelns". Diese Daten muss ich nur solange aufheben, bis der Arbeitnehmer wieder ausstempelt oder das Projekt wechselt, weil dann der Zeiteintrag geschrieben wird

[...]

gibt es sonst noch gute Möglichkeiten?

Du könntest beim "Einstempeln" nur die Einstempelzeit in den Zeitplan speichern (also in der Datenbank); und beim "Ausstempeln" den Eintrag vervollständigen. Daraus lässt sich dann dynamisch "berechnen", ob ein Arbeitnehmer gerade arbeitet und woran.

Beispiel: models.py, Shell-Session, die das Demonstriert