IRC logs of #tryton for Friday, 2008-10-10

chat.freenode.net #tryton log beginning Fri Oct 10 00:00:01 CEST 2008
X0d_of_N0dWhy use mx.DateTime instead of time.strptime??00:29
-!- yangoon(n=mathiasb@p549F482B.dip.t-dialin.net) has joined #tryton05:18
-!- X0d_of_N0d(i=C-C_C-X@gateway/tor/x-ffe4a04d0214a6f8) has joined #tryton07:40
-!- Gedd(n=ged@77.109.115.127) has joined #tryton08:01
-!- bechamel(n=user@user-85-201-14-207.tvcablenet.be) has joined #tryton08:44
-!- markusleist(n=markus@n4-82.dsl.vianetworks.de) has joined #tryton08:55
-!- GeE(n=gzuerche@host2.raptus.com) has joined #tryton09:00
-!- gadaga(n=gael@sednaco19320-gw.clients.easynet.fr) has joined #tryton09:04
gadagahi09:04
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton09:39
-!- gael_(n=gael@sednaco19320-gw.clients.easynet.fr) has joined #tryton10:49
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 824:3cd811266b3e tryton/ (3 files in 3 dirs): Remove unusefull message_box10:51
-!- udono(n=udono@dynamic-unidsl-85-197-19-103.westend.de) has joined #tryton11:32
udonogood morning11:43
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 827:976c2cc988a8 tryton/ (share/tryton/tryton.glade tryton/common/common.py): Remove win_selection from glade11:44
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 226:47fc0ca456a4 account/move.py: Remove positive constraint on debit/credit for account move lines11:55
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 1083:f76dabd4ab51 trytond/trytond/ (osv/osv.py report/report.py wizard/wizard.py): Remove unused CLASS_POOL13:17
-!- ikks(i=igor@190.157.145.193) has joined #tryton13:43
-!- ikks(n=igor@190.12.153.202) has joined #tryton14:36
-!- X0d_of_N0d(i=C-C_C-X@gateway/tor/x-9bc946872dfd8096) has joined #tryton14:47
cedkhi, anybody know a way to write sql query that have the same behavior than the aggregate function First ?15:19
cedkit is for the historisation, I have a table with one record for each changes15:22
cedkso if I want to have the record value at a specific date, I need the first value not null for each columns15:23
cedkand I don't see how to make it with a single query15:23
bechamelcedk: its a (key, value, date) table ?15:27
udonocedk: dont understand? Have an example?15:28
cedkbechamel: no15:29
cedkhere, an example: http://rafb.net/p/9Tfu4X51.html15:30
cedkyou see that the record 3 has been modified 3 times15:31
bechamelcedk: the easiest thing to do is to populate all columns15:32
cedkwith more values: http://rafb.net/p/Epajta26.html15:32
udonoyou can select ... order by create_date limit=115:32
udonocedk:15:32
cedkbechamel: but so we need to read all the values15:32
cedkudono: no, because I will not have all the values15:33
bechamelcedk: and if you think it's to much data in the db, maybe the best is to use a key-value table15:33
udonocedk: limit=115:33
cedkudono: no, because you have field with null value15:33
cedkbechamel: key-value table are not good because you don't have the right column type15:33
cedkbechamel: it is like the ir.value table in openerp15:34
cedkbechamel: it is bad stuff15:34
cedkthere is a aggrgator First but it is an oracle specific15:34
cedkand there example to implement it in postgres, http://archives.postgresql.org/pgsql-hackers/2006-03/msg01324.php15:35
bechamelcedk: yes but where not talking about a regular table here, you dont need constraint, foreign key and so on15:35
cedkbechamel: yes but for search it will be too complicated15:35
cedkbechamel: and you need to make many insert for one record changed15:35
bechamelcedk: if you want to implement search, it will be also difficult with your nearly-empty table (i dont know how to call it)15:38
udonocedk: SELECT id, name FROM table where name IS NOT NULL LIMIT 1 ORDER BY create_date;15:40
bechamelcedk: actualy what you show is nearly a key-value table, except when changing two value on the same record15:40
udonocedk: SELECT id, name FROM table where name IS NOT NULL LIMIT 1 ORDER BY create_date DESC;15:40
cedkbechamel: but if I fill it, it will use many spaces on the disk and you will not be able to know what was really modify15:40
bechameludono: the problem is when there is more than one search criteria15:41
udonobechamel: AND, OR ?15:41
cedkudono: you must have one query per field, it is not very efficient15:41
cedkbechamel: search is not for now the main issue15:41
bechameludono: yes if i search for name = test and menu = 4, what will you do ?15:42
cedkin fact search has not many sence15:43
bechamelcedk: what happen if i do "update user set menu = null where id =3" what do you put in the history table ?15:43
bechamelcedk: why?, it's actually a key feature of apple timemachine15:44
cedkbechamel: you are right the update to null is not catch15:44
bechamelcedk: and i dont know if the table will be very big, most of the tables are create-read only. I don't see a lot of table with intensive write on it15:45
cedkbechamel: I don't think you can search for the time where a file has this word and an other one an other word15:45
bechamelcedk: it could be interessting to search across all user who had a certain menu15:47
udonobechamel: SELECT id, name FROM table where name IS NOT NULL LIMIT 1 ORDER BY create_date UNION SELECT menu FROM table where name IS NOT NULL AND menu=4 LIMIT 1 ORDER BY create_date;15:47
bechameludono: yes, the solution is to make one join or one union by query arg, but join is better :)15:48
udonoI think I dont understand where the problem is... refused15:49
bechameludono: but the problem with join is that joining on the id is not enough, and i dont know how to join on the date15:49
-!- CIA-52(n=CIA@208.69.182.149) has joined #tryton15:50
udonobechamel: but id is not unique, afais, but date is unique, so its our primary key, or isn't it?15:51
-!- X0d_of_N0d(i=C-C_C-X@gateway/tor/x-07cc6fbe42adb4e0) has joined #tryton15:52
bechamelcedk: and if a table is the target of a lot of write, probably it's not very interesting to keep all the history, maybe one can think of three way of historization: synchronous, once per min/hour/day or nothing15:53
bechameludono: my bet is that the primary key is (id,date).15:56
udonobechamel: ok, combined is even more secure. But whats the problm to use date in the ON condition of a join?15:56
bechameludono: there isn't two line with the same date so "join on (A.date = B.date)" will alwayes lead to zero result15:59
bechameludono: subselect may work16:00
udonobechamel: yes, with <, >operators and limit=1 you get the nearest hit of the seached date16:02
udonobechamel: and of course the right sort order...16:03
cedkof course it can works but you will have many join and the query will be not very efficient16:13
cedkthe best for now, is to use the first aggregator16:14
cedkbechamel: there is no sence to historize a table for delete it after16:14
bechamelcedk: yes, and there is the same problem with a key-value table, actualy the two modelisation are very similar with respect to the way that the data can be accessed16:15
bechamelcedk: i didn't talk about deleting it after, i talk about not storing all the write16:17
bechamelcedk: and how can you tell that the agregator is more efficient than a subselect ?16:18
cedkbechamel: with subselect postgres needs to read each time the table16:22
cedkbechamel: as it will do each select and after construct the result16:22
bechamelcedk: my preference goes to an implementation where all the column are written in the history table, because 1) there is more create than write on most table 2) it will be more poweful or easier to implement or with more feature (or the three at the same time )16:22
cedkbechamel: it will be very less efficient, as when you update many record with the same value, you need to read it all16:24
cedkbechamel: and I think that the null issue can be fixed by adding not null on each records16:25
cedkbechamel: because null on char means '' in the client interface16:26
cedkbechamel: null on integer is not allow16:26
bechamelcedk: and on foreing key16:26
bechamelcedk: ?16:26
cedkbechamel: thinking16:26
cedkthe union query doesn't work16:29
bechamelcedk: and for the efficiency, it's not needed to read the original table to write on the history table, you can do: "insert into history table, values (select from original where id = %s)" or something similar16:29
cedkbechamel: for many2one, we can store in the history table 016:29
cedkbechamel: but you don't know what have been write on the record16:30
cedkbechamel: and I think I have a solution for all the null issue16:30
cedkbechamel: for many2one, store -1 is better16:31
bechamelcedk: puttin 0 instead of null is a bad idea imo, it's ok not to use some db feature but it's not ok hijack feature with "one can tell the 0 means null"16:32
bechamelcedk: -1 ? and what about fk integrity ?16:32
cedkbechamel: there is no integrity in history table16:33
bechamelcedk: maybe you want to drop fk also ?16:33
cedkbechamel: for history, there will be any constraint16:33
bechamelcedk: and for the insert exemple i gave, i don't understand why you tell that i don't what have written on the record, i don't need to know it16:35
bechamelcedk: and for the insert exemple i gave, i don't understand why you tell that i don't KNOW what I have written on the record, i don't need to know it16:36
cedkbechamel: good historization must tell you what the user has writte and not just the result16:36
bechamelcedk: if you want to know what have change you check the last line with the same id16:39
cedkbechamel: I don't mean what has changed but what the user write16:40
bechamelcedk: what the difference ?16:40
cedkbechamel: if I write the same value, I don't see a change16:41
bechamelcedk: in this case we must not create a new record in the history table16:43
cedkbechamel: why, there was an action and you will not keep track of it16:44
bechamelcedk: if it's the only drawback, one can tell that it's nearly perfect :)16:46
cedkbechamel: after some googling, it seems that your proposition is the most used for historisation16:47
cedkbechamel: I would like to preserve space on disk16:48
cedkbechamel: but it set the queries more complicated16:48
cedkso I will put all the values16:48
bechamelcedk: great16:49
bechamelcedk: and i think that keeping fk should be also possible, but i don't if it's usefull16:50
bechamel...i don't know .. (once again)16:51
cedkbechamel: if the foreign key is deleted, then you will lost the value in the history table16:52
bechamelcedk: yes, i was thinking about creating a fk across history tables directly16:53
cedkbechamel: but it is not usefull16:54
bechamelcedk: maybe if one want to "browse" data at a certain date in the past. but it's possible to do it without the fk.16:56
bechamelcedk: it depend also of other implementation decision, do you plan to create a record in the history table when a record is created on the original table ?16:57
cedkbechamel: yes and also when it is deleted16:58
bechamelcedk: so it's easier to implement fk to the historical table (because whitout it i don't know what to put as fk if there is not record in the history table, ie an original record without update)17:01
cedkbechamel: no, because you will need to historize all the fk models and than you will need to historize all the tables17:02
bechamelcedk: yes, it work only if the target table is historized, but if it's not historized and that the fk point to the original table, there is a risk that the target record  disappear.17:07
cedkbechamel: it is not a risk, it is a choice17:08
cedkbechamel: if the user doesn't want to historize the traget table17:08
bechamelcedk: once again it's a balance between feature and ease of implementation17:08
cedkbechamel: fk is not a feature17:08
cedkbechamel: it is a constraint17:08
cedkbechamel: to check the integrity17:09
cedkbechamel: but for historisation, we don't need integrity17:09
bechamelcedk: having a link directly to the good historical record at the correct time is a feature17:09
cedkbechamel: it is not a link a foreign key, it is a constraint !!!17:10
bechamelcedk: yes but a fk is also an index17:11
bechamelcedk: you can join on it17:11
bechamelcedk: efficiently17:11
cedkbechamel: I'm not sure the fk is also index17:13
cedkbechamel: in the postgres documentation, they don't say that it is also an index17:15
bechamelcedk: you are right, the index is the result of the primary key not the foreing key that point to it17:26
-!- ikks(n=igor@190.12.153.202) has joined #tryton18:30
cedkikks: hi19:00
cedkikks: we have fixed the release dates: http://www.tryton.org/community/calendar.html19:00
ikksclick19:00
-!- X0d_of_N0d(i=C-C_C-X@gateway/tor/x-58e4d0056dc95ae5) has joined #tryton19:40
ikkscedk: thanks :) . The bad news are that I'll be offline from a few moments until monday night.19:48
ikksFor the moment I would be able to send a tar.gz with the strings that are translated.19:48
ikkshttp://dpaste.com/83676/19:50
ikksThis is what I have for now.19:50
ikksHope to be sending by tuesday in the proper way.19:51
ikksbug -> forest diff19:51
ikksor19:51
ikksbug -> mercurial public repository19:51
-!- X0d_of_N0d(i=C-C_C-X@gateway/tor/x-b0259dbc59e60e18) has joined #tryton19:52
ikksbye, bye19:55
cedkfor people who want to test the history, I can give access to the repository20:40
X0d_of_N0dcedk: what exactly are you tring to do... from a higer level, not the query you're looking for21:56
X0d_of_N0d?21:56
-!- X0d_of_N0d(i=C-C_C-X@gateway/tor/x-b5ba7bedeadf2b11) has joined #tryton22:01
CIA-52tryton: Bertrand Chenal <bch@b2ck.com> default * 72:9d3e25e01fb6 stock_supply/purchase_request.py: Test for missing data earlier in the wizard22:07
CIA-52tryton: Bertrand Chenal <bch@b2ck.com> default * 73:c0be7eb10b89 stock_supply/purchase_request.py: Don't use search to check supplier payment term22:07
-!- Gedd(n=ged@77.109.113.231) has joined #tryton22:12
udonocedk: me want to test22:24
CIA-52tryton: udo.spallek * r170 /wiki/Release100.wiki: Created wiki page through web user interface.22:26
CIA-52tryton: udo.spallek * r171 /wiki/Release100.wiki: Deleting wiki page Release100.22:26
CIA-52tryton: udo.spallek * r172 /wiki/Release_1_0_0.wiki: Created wiki page through web user interface.22:26
CIA-52tryton: udo.spallek * r173 /wiki/Release_1_0_0.wiki: Edited wiki page through web user interface.22:26
CIA-52tryton: udo.spallek * r174 /wiki/ReleaseGeneral.wiki: Created wiki page through web user interface.22:26
CIA-52tryton: udo.spallek * r175 /wiki/ReleaseGeneral.wiki: Edited wiki page through web user interface.22:26
CIA-52tryton: udo.spallek * r176 /wiki/Release_1_0_0.wiki: Edited wiki page through web user interface.22:26
CIA-52tryton: udo.spallek * r177 /wiki/ReleaseGeneral.wiki: Edited wiki page through web user interface.22:26
CIA-52tryton: udo.spallek * r178 /wiki/ReleaseGeneral.wiki: Edited wiki page through web user interface.22:26
CIA-52tryton: udo.spallek * r179 /wiki/Release_1_0_0.wiki: Edited wiki page through web user interface.22:26
CIA-52tryton: udo.spallek * r180 /wiki/Release_1_0_0.wiki: Edited wiki page through web user interface.22:26
CIA-52tryton: cedric.krier@b2ck.com * r181 /wiki/Release_1_0_0.wiki: Edited wiki page through web user interface.22:26
CIA-52tryton: cedric.krier@b2ck.com * r182 /wiki/ReleaseGeneral.wiki: Edited wiki page through web user interface.22:26
CIA-52tryton: matb roundup * #417/Translation: updates for de_DE: [chatting] AFAIS this makes necessary to put all repos from tryton.org on different repos somewhere, i.e. all different modules in one repos each. ...22:50
CIA-52tryton: Bertrand Chenal <bch@b2ck.com> default * 74:66bc1f7a56a2 stock_supply/ (de_DE.csv purchase_request.py purchase_request.xml): Better name: use purchase.request instead of stock.purchase_request23:03
CIA-52tryton: udo.spallek * r183 /wiki/DevelSnippets.wiki: Edited wiki page through web user interface.23:22
CIA-52tryton: ced roundup * #417/Translation: updates for de_DE: On 10/10/08 22:50 +0200, Mathias wrote: > > Mathias <mathias.behrle@gmx.de> added the comment: > > AFAIS this makes necessary to put all repos f ...23:54
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 828:bf8518bac51f tryton/tryton/common/common.py: Remove set_has_separator on MessageDialog23:59

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