| chat.freenode.net #tryton.de log beginning Wed Oct 14 00:00:02 CEST 2009 | ||
| -!- yangoon(n=mathiasb@p549F7149.dip.t-dialin.net) has joined #tryton.de | 05:19 | |
| -!- Timitos(n=timitos@88.217.184.172) has joined #tryton.de | 07:07 | |
| -!- MarkusB(n=burli@dslb-094-219-150-233.pools.arcor-ip.net) has joined #tryton.de | 08:32 | |
| -!- udono(n=udono@85.197.24.144) has joined #tryton.de | 10:07 | |
| -!- paepke(n=paepke@217.6.201.92) has joined #tryton.de | 10:38 | |
| -!- paepke(n=paepke@217.6.201.92) has joined #tryton.de | 11:41 | |
| -!- paepke(n=paepke@Rabb2.r.pppool.de) has joined #tryton.de | 17:34 | |
| -!- ma_bo(n=mb@statdsl-085-016-072-173.ewe-ip-backbone.de) has joined #tryton.de | 18:44 | |
| -!- johbo(n=joh@statdsl-085-016-072-173.ewe-ip-backbone.de) has joined #tryton.de | 18:45 | |
| paepke | @all: ich hatte in errinnerung das man die historisierung quasi jedem model hinzufügen kann. siehe die beiden (code-technisch unterschiedlichen) ansätzen mit product_cost_history und account_invoice_history. stimmt das soweit? | 20:18 |
|---|---|---|
| udono | paepke: ja, das stimmt | 20:34 |
| paepke | udono: und so wie ich verstanden habe wird einfach eine kopie des letzten datensatzes in die tabelle tabellenname__history eingefügt. | 20:35 |
| paepke | udono: vom prinzip her. | 20:37 |
| udono | ja, genau. Diese Tabelle wird bei jeder Änderung erweitert. Nie 'geupdatet' oder gelöscht | 20:37 |
| paepke | wird die history anhand von reports irgendwie automagisch herangezogen? beispiel: verlauf der produktkosten innerhalb einer produkt-kategorie? oder muss man dies dann selbst beachten? | 20:43 |
| paepke | rein theoretisch. ob es den report schon gibt ist jetzt gerade egal. | 20:44 |
| udono | paepke: gute Frage | 20:51 |
| paepke | udono: danke :-D | 20:51 |
| udono | paepke: eigentlich sollte die history low level gelöst sein, so dass die höheren Funktionen nichts davon mitbekommen | 20:52 |
| udono | paepke: hast du die Datenbankstruktur von Historyeinträgen schon analysiert? | 20:53 |
| paepke | nein noch nicht. ich hab es noch nicht im einsatz. aber gleich... | 20:53 |
| udono | paepke: ok | 20:53 |
| udono | paepke: BTW es gibt bisher nicht die Möglichkeit, die History Einträge eines Models darzustellen | 20:54 |
| udono | paepke: bei den Reports denke ich kann man das realisieren durch direkte Datenbankabfragen in SQL | 20:55 |
| udono | paepke: bei den views kursiert bisher nur die Idee, es so zu machen wie MacOS timemachine http://www.apple.com/macosx/features/timemachine.html | 20:57 |
| paepke | timemachine kenn ich. | 20:57 |
| paepke | ich hab akut das problem das ich zurück in die zukunft will | 20:57 |
| paepke | also änderungen in der zukunft machen (model ist gültig bis, ab dann anderer datensatz) | 20:58 |
| udono | paepke: und die Anwendung? | 20:59 |
| udono | ... außer 'nen Film produzieren | 21:00 |
| paepke | beispiel: mitarbeiter heiratet im november und heisst dann anstann paepke zukünftig spallek | 21:00 |
| udono | paepke: wo ist das problem? | 21:00 |
| paepke | anstann => anstatt | 21:00 |
| paepke | oder man weiss das nächstes jahr die Ust auf 55% anwächst. | 21:01 |
| udono | paepke: Also realisieren lässt sich das bereits mit dem Scheduler | 21:02 |
| paepke | ich brauch den stand aber was in der zukunft, vergangenheit und auch jetzt gerade gülitg ist / war. | 21:02 |
| udono | paepke: allerdings nur für einige wenige Vorgänge, wie zum Beispiel Bestellpunkte | 21:02 |
| udono | paepke, ja, aber wofür? | 21:03 |
| paepke | ich hab ein ev. projekt für das ich gerade ein absteckung des aufwandes mache. | 21:03 |
| paepke | schulungs/mitarbeitermanagement. | 21:03 |
| udono | Das brauchst du aber doch nicht für jedes Eingabefeld im gesamten System. | 21:03 |
| paepke | da ist das absolut üblich ein versionierbarer personalstamm ähnlicherer daten zu haben. | 21:04 |
| paepke | udono: nicht im gesamten system. ich tipp kurz noch ein beispiel: | 21:04 |
| paepke | mitarbeiter wechselt in 2 monaten in eine andere abteilung. ergo ändert sich die kompetenzmatrix: der mitarbeiter braucht dann verschiedenen schulungen. diese müssen geplant und budgetiert werden. | 21:05 |
| udono | paepke: die history von Tryton kann das glaube ich nicht | 21:07 |
| paepke | udono: ja, das kann die history nicht. | 21:07 |
| udono | paepke: ich schaue mir gerade den implementierungspatch an: http://www.b2ck.com/~ced/history.patch | 21:08 |
| paepke | udono: ich hatte gehofft du überrascht mich mit modul_x welches das kann ;-) | 21:08 |
| paepke | udono: bevor ich das nur für mein neu zu entwickelndes modul bauen werde hätte es ja auch sein können das hier etwas generisches da ist. oder das man etwas generisches entwickelt. | 21:10 |
| paepke | das würde halt ganz tief rein gehen ins system | 21:10 |
| udono | paepke: man könnte das realisieren | 21:11 |
| udono | paepke, man müsste für jeden history eintrag auch ein gültigkeitsdatum angeben können | 21:12 |
| paepke | primitiv gedacht sind es zwei weitere spalten valid_from und valid_to | 21:12 |
| paepke | udono: ist die frage ob das in eine history-tabelle kommt oder eben nicht auf die haupt-tabelle kommt? ich sehe es eher dort. | 21:13 |
| paepke | weil ich arbeite ja mit den daten. und zukünftige daten sind eher nicht in einer history tabelle drin. | 21:13 |
| udono | paepke: gute Frage | 21:13 |
| paepke | udono: mit jobs kann man ja um die haupt-tabelle zu entschlacken sachen in eine history verschieben. | 21:14 |
| paepke | udono: da ist glaub noch ein wenig denkschmalz erforderlich. | 21:14 |
| udono | paepke: das ist die Frage. Soll die Vergangenheit manipulations sicher sein oder nicht? | 21:14 |
| paepke | udono: naja. theoretisch schon. aber die wirklichkeit sieht meist anders aus... | 21:15 |
| paepke | udono: ich sage jetzt trotzdem mal: ja. | 21:15 |
| udono | paepke: Dann habe ich eine Idee | 21:16 |
| paepke | mir fällt ausser das system für wirtschaftsprüfer zu fälschen kein use case ein. | 21:16 |
| -!- paepke(n=paepke@Rabb2.r.pppool.de) has joined #tryton.de | 22:34 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!