IRC logs of #tryton.de for Wednesday, 2009-10-14

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.de05:19
-!- Timitos(n=timitos@88.217.184.172) has joined #tryton.de07:07
-!- MarkusB(n=burli@dslb-094-219-150-233.pools.arcor-ip.net) has joined #tryton.de08:32
-!- udono(n=udono@85.197.24.144) has joined #tryton.de10:07
-!- paepke(n=paepke@217.6.201.92) has joined #tryton.de10:38
-!- paepke(n=paepke@217.6.201.92) has joined #tryton.de11:41
-!- paepke(n=paepke@Rabb2.r.pppool.de) has joined #tryton.de17:34
-!- ma_bo(n=mb@statdsl-085-016-072-173.ewe-ip-backbone.de) has joined #tryton.de18:44
-!- johbo(n=joh@statdsl-085-016-072-173.ewe-ip-backbone.de) has joined #tryton.de18: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
udonopaepke: ja, das stimmt20:34
paepkeudono: und so wie ich verstanden habe wird einfach eine kopie des letzten datensatzes in die tabelle tabellenname__history eingefügt.20:35
paepkeudono: vom prinzip her.20:37
udonoja, genau. Diese Tabelle wird bei jeder Änderung erweitert. Nie 'geupdatet' oder gelöscht20:37
paepkewird 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
paepkerein theoretisch. ob es den report schon gibt ist jetzt gerade egal.20:44
udonopaepke: gute Frage20:51
paepkeudono: danke :-D20:51
udonopaepke: eigentlich sollte die history low level gelöst sein, so dass die höheren Funktionen nichts davon mitbekommen20:52
udonopaepke: hast du die Datenbankstruktur von Historyeinträgen schon analysiert?20:53
paepkenein noch nicht. ich hab es noch nicht im einsatz. aber gleich...20:53
udonopaepke: ok20:53
udonopaepke: BTW es gibt bisher nicht die Möglichkeit, die History Einträge eines Models darzustellen20:54
udonopaepke: bei den Reports denke ich kann man das realisieren durch direkte Datenbankabfragen in SQL20:55
udonopaepke: bei den views kursiert bisher nur die Idee, es so zu machen wie MacOS timemachine http://www.apple.com/macosx/features/timemachine.html20:57
paepketimemachine kenn ich.20:57
paepkeich hab akut das problem das ich zurück in die zukunft will20:57
paepkealso änderungen in der zukunft machen (model ist gültig bis, ab dann anderer datensatz)20:58
udonopaepke: und die Anwendung?20:59
udono... außer 'nen Film produzieren21:00
paepkebeispiel: mitarbeiter heiratet im november und heisst dann anstann paepke zukünftig spallek21:00
udonopaepke: wo ist das problem?21:00
paepkeanstann => anstatt21:00
paepkeoder man weiss das nächstes jahr die Ust auf 55% anwächst.21:01
udonopaepke: Also realisieren lässt sich das bereits mit dem Scheduler21:02
paepkeich brauch den stand aber was in der zukunft, vergangenheit und auch jetzt gerade gülitg ist / war.21:02
udonopaepke: allerdings nur für einige wenige Vorgänge, wie zum Beispiel Bestellpunkte21:02
udonopaepke, ja, aber wofür?21:03
paepkeich hab ein ev. projekt für das ich gerade ein absteckung des aufwandes mache.21:03
paepkeschulungs/mitarbeitermanagement.21:03
udonoDas brauchst du aber doch nicht für jedes Eingabefeld im gesamten System.21:03
paepkeda ist das absolut üblich ein versionierbarer personalstamm ähnlicherer daten zu haben.21:04
paepkeudono: nicht im gesamten system. ich tipp kurz noch ein beispiel:21:04
paepkemitarbeiter 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
udonopaepke: die history von Tryton kann das glaube ich nicht21:07
paepkeudono: ja, das kann die history nicht.21:07
udonopaepke: ich schaue mir gerade den implementierungspatch an: http://www.b2ck.com/~ced/history.patch21:08
paepkeudono: ich hatte gehofft du überrascht mich mit modul_x welches das kann ;-)21:08
paepkeudono: 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
paepkedas würde halt ganz tief rein gehen ins system21:10
udonopaepke: man könnte das realisieren21:11
udonopaepke, man müsste für jeden history eintrag auch ein gültigkeitsdatum angeben können21:12
paepkeprimitiv gedacht sind es zwei weitere spalten valid_from und valid_to21:12
paepkeudono: 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
paepkeweil ich arbeite ja mit den daten. und zukünftige daten sind eher nicht in einer history tabelle drin.21:13
udonopaepke: gute Frage21:13
paepkeudono: mit jobs kann man ja um die haupt-tabelle zu entschlacken sachen in eine history verschieben.21:14
paepkeudono: da ist glaub noch ein wenig denkschmalz erforderlich.21:14
udonopaepke: das ist die Frage. Soll die Vergangenheit manipulations sicher sein oder nicht?21:14
paepkeudono: naja. theoretisch schon. aber die wirklichkeit sieht meist anders aus...21:15
paepkeudono: ich sage jetzt trotzdem mal: ja.21:15
udonopaepke: Dann habe ich eine Idee21:16
paepkemir 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.de22:34

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!