Zeiterfassung mit Django auslesen

[FuzzyLogic]

Hallo Zusammen,

Ich möchte mithilfe von Django eine Anwesenheitstabelle unserer Mitarbeiter erstellen.

Dazu hatte ich angedacht einen "Read-Only" Benutzer in der ZEF-Datenbank anzulegenen und in Django in der Setup.py die Datenbank als "zweit Datenbank" anzulegen. Dann wollte ich mithilfe von

Code: Alles auswählen

Manage.py inspectdb

die Strucktur der Datenbank in meinen Models nachbauen.
Problematisch ist, dass unsere Zeiterfassung eine FirebirdSQL Datenbank ist und ich Django 1.8.x verwende. Für diese Version von Django gibt es keinen Datenabanktreiber, also ist ein direktes Abfragen aus der, auf diesem Weg, ZEF-Datenbank nicht möglich.

Mein alternativer Plan ist alle x Sekunden eine Kopie der Zeiterfassungsdatenbank zu erstellen und diese mit Django einzulesen. Das sind allerdings eine Menge Daten und die Methode wäre meiner Meinung nach eher unschön.

Habt ihr Ideen, wie ich am besten vorgehen soll?

Grüße

[BlackJack]

@FuzzyLogic: Ich würde da eher schauen ob/wie man die vorhandene Datenbank in Django integrieren kann. Vielleicht gibt's da ja schon ein Plugin für oder Du schaust mal wie aufwändig das wäre eines selber zu schreiben. Eventuell geht es auch via SQLAlchemy (SA) falls es da eine Anbindung für Django gibt, denn SA hat Firebird als Dialekt dabei.

[kbr]

@FuzzyLogic: kurzes googeln führt Dich hierhin:
https://pypi.python.org/pypi/django-firebird/1.6.4
Falls das nicht mit Django 1.8 läuft, dann nimmst Du eben 1.6 (falls Dir das erlaubt ist); oder SA, wie BlackJack schrieb.

[DasIch]

Falls das nicht mit Django 1.8 läuft, dann nimmst Du eben 1.6 (falls Dir das erlaubt ist); oder SA, wie BlackJack schrieb.

Django 1.6 wird nicht mehr unterstützt und bekommt keine Sicherheitsupdates mehr. Vollkommen egal ob es ihm erlaubt ist oder nicht es zu benutzen, es wäre unverantwortlich es zu benutzen.

[FuzzyLogic]

Vielen Dank für die schnellen Antworten!

Django 1.6 wird nicht mehr unterstützt und bekommt keine Sicherheitsupdates mehr. Vollkommen egal ob es ihm erlaubt ist oder nicht es zu benutzen, es wäre unverantwortlich es zu benutzen.

Genau das ist der Grund, weshalb ich nicht schon längst auf 1.6 gewechselt habe.

Eventuell geht es auch via SQLAlchemy (SA) falls es da eine Anbindung für Django gibt, denn SA hat Firebird als Dialekt dabei.

SQLAlchemy zu verwenden anstatt das Django ORM schaut nach einem guten Lösungsansatz aus. Ich versuche mal es nach der Anleitung unter:
http://lethain.com/replacing-django-s-o ... qlalchemy/

Allerdings würde ich das Django ORM gerne Ergänzen und nicht ersetzen. Ich möchte auch noch weitere Models verwenden um Benutzer zu verwalten, Farbschemen und Filteroptionen zu speichern, etc. Diese sollen dann, falls möglich, in einer SQLite3-DB abgelegt werden.

Ich probiere es mal und melde mich mit dem Ergebnis.

Falls euch noch eine bessere Lösung einfällt, könnt ihr euch gerne melden

Grüße

[jerch]

Ich hab selbst nie den Django-ORM ausgetauscht, könnte mir aber vorstellen, dass Du mit der Aktion etliche nette hochintegrierte Features von Django verlierst. Für mich wäre das eher Option C.

Evtl. lässt sich ein Django-zu-SA-Proxy mit einem abstrakten Model bauen, indem Du die Primitive wie `save` direkt an SA durchreichst und für Abfragen entsprechende Manager baust. Könnte zum Performancegau werden und würde ich nur probieren, wenn die Bearbeitung der Datensätze der Firebird-DB die Ausnahme bleiben soll.

[kbr]

Django 1.6 wird nicht mehr unterstützt und bekommt keine Sicherheitsupdates mehr. Vollkommen egal ob es ihm erlaubt ist oder nicht es zu benutzen, es wäre unverantwortlich es zu benutzen.

Wenn es nur intern verwendet wird und es allein auf die geforderte Funktionalität ankommt, stellt sich die Frage nach zukünftigen Sicherheitsupdates möglicherweise anders. Daher mein Hinweis auf 1.6. Natürlich beginnt man ein neues Projekt mit einer aktuellen Version (es sei denn, es gibt gute Gründe dies nicht zu machen). In der Praxis ist es zudem oft so, dass einmal erstellte Projekte lange laufen und nicht immer zeitnah (wenn überhaupt) auf neue Major-Update hochgezogen werden (Aufwand, zu teuer, kein Etat - die üblichen Gründe). Wenn Du als Mitentwickler nun von "unverantwortlich" sprichst, dann ergibt sich allerdings die Frage, wie schlimm es denn konkret um 1.6.11 bestellt ist.