IRC logs of #tryton for Thursday, 2010-08-26

chat.freenode.net #tryton log beginning Thu Aug 26 00:00:02 CEST 2010
-!- Hydrant(~aj@unaffiliated/hydrant) has joined #tryton01:00
HydrantI'm not sure I'm a fan of the fact trytond.conf is world-readable by default in my install01:00
-!- sharoon(~sharoon@vpn21.its.manchester.ac.uk) has joined #tryton01:20
-!- gremly(~gremly@190.147.153.138) has joined #tryton01:36
-!- gremly(~gremly@190.147.153.138) has joined #tryton02:08
-!- pheller(~pheller@2002:ad30:d8c3:0:fa1e:dfff:fee6:aabf) has joined #tryton02:16
-!- digitalsatori(~tony@116.233.243.167) has joined #tryton02:47
-!- ikks(~ikks@190.158.116.172) has joined #tryton03:05
-!- woakas(~woakas@pcsp163-59.supercabletv.net.co) has joined #tryton03:26
-!- digitalsatori(~tony@116.233.243.167) has joined #tryton03:50
-!- gremly(~gremly@190.26.186.242) has joined #tryton04:06
-!- yangoon(~mathiasb@p549F7189.dip.t-dialin.net) has joined #tryton05:19
-!- evernichon(~evernicho@mailout.fief.ch) has joined #tryton08:05
-!- eLBati(~elbati@94.165.1.168) has joined #tryton08:25
-!- Okko(~Okko@62.58.29.41) has joined #tryton08:46
-!- paepke(~paepke@p4FEB6299.dip.t-dialin.net) has joined #tryton09:00
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton09:14
-!- enlightx(~enlightx@host198-217-dynamic.14-87-r.retail.telecomitalia.it) has joined #tryton09:44
-!- bechamel(~user@chimie-prtx11.scf.fundp.ac.be) has joined #tryton09:59
paepkegood morning cedk. i'm currently evolving a attachment backend based on a nosql database. I have two concepts. the easy one: just replacing the get_data and set_date functions. And the hard one: introducing a new StorageModel which won't be compatible with the sql one.10:18
paepkecedk, i've found no other dependencies on the attachments like joins or using that data model directly, except the webdav.py10:19
paepkecedk, do you have any suggestions or something i didn't get already?10:19
bechamelpaepke: your goal is to replace the filesystem with a nosql db for the attachements or to provide a new backend that will replace postrgesql ?10:24
paepkebechamel, thats the question. i want to replace the attachment system and that is build on filesystem and postgresql. it would be better to have all data in nosql. not only the file.10:25
paepkebechamel, but i don't wanna write a backend to replace other modules with a sql backend like party or product.10:26
bechamelpaepke: ok10:26
bechamelpaepke: nothing prevent you to implement the easy solution and after extend it10:32
paepkebechamel, yes, youre right.10:38
bechamelIMO the difficult par of a "ModelNoSQL" that would replace ModelSQL is the search method10:39
bechamelpaepke: btw wich nosql db do you plan to use ?10:39
paepkebechamel, i wanna use couchdb, as i have a specific problem, which can't be done using mongodb.10:40
paepkebechamel, thats not tryton related :-)10:40
bechamelactually the biggest problem, with those db is the lack of concurency support (or at least the different approach)10:43
paepkebechamel, its not a bug, its a feature10:44
paepkebut you are right. you have to deal with sync-problems if there are two conflicting edits.10:45
paepkeimo replacing the ModelSQL in the whole system doesn't make sense. at least not for the current modules.10:46
paepkenevertheless its perfect replacement for the attachment module.10:47
bechamelpaepke: also what happens in case of a hardware failure when an attachement is saved ? is there any journal to cleann stuff after the failure ? this would be a regression compared to the fs storage10:47
paepkebechamel, if its not written you did not get back an "ok"10:50
-!- Red15(~red15@unaffiliated/red15) has joined #tryton10:55
yangoonpaepke: what are the principle advantages from nosql oder fs? better search?10:56
yangoons/oder/over/10:57
paepkeyangoon, better replication (based on document fields), better search could be. not investigated.10:59
yangoonpaepke: so you are developing it just for the replication advantage?11:01
paepkeyangoon, no, not only.11:01
paepkeyangoon, replication: i have a use case where files were stored in a web application which runs outside the customers network to give access to his customers. they can upload files for themselves.11:03
paepkeyangoon, the customer wants that the files will be magically available in both systems. local tryton and remote web application. but of course not every file.11:04
paepkeyangoon, thats were the field based replication comes into account.11:05
paepkewhere....11:06
yangoonpaepke: and the web app uses already nosql db?11:06
paepkeyangoon, no.11:08
paepkeyangoon, but its prepared.11:08
yangoonpaepke: it is an interesting issue, just to check: which detail is preventing to use a connector to tryton instead rewriting the attachment system?11:10
paepkeyangoon, its an unreliable connection, pulling from the web is not usable (firewalling issues). and couchdb has the solution for both problems.11:13
yangoonpaepke: IC, thx11:15
paepkeyangoon, anyway its not easy to replicate filesystem based storage to other nodes. cluster filesystems were not funny to use. thats a lot easier with such a document based storage.11:15
paepkeyangoon, especially if you only use read/write/search on the files.11:16
yangoonpaepke: if you need replication, then yes11:16
paepkeyangoon, its even a multi-master setup. documents can be uploaded via the local customer site and the web-application.11:16
paepkeyangoon, so my idea was to use couchdb to modify the attachment part and have all my problems solved by it.11:17
paepkeyangoon, hopefully11:17
yangoonpaepke: and get some new problems...;)11:18
paepkeyangoon, i try to prevent this :-)11:18
paepkeyangoon, and its an interesting projectg11:18
yangoonpaepke: I see the concurrenc problem, as bechamel already said11:18
paepkeyangoon, why? please explain11:21
yangoon paepke it depends on the layout: if you allow to write documents from local network as well as from the web app, documents could be updated simultaneously on both sides11:23
paepkeyes, you have to take care of such a problem. that is by design.11:26
paepkefor a local deployment (not my veryspecific use case) you can use kind of a master/slave layout. where you limit the writes to only one master and use continious replication to the slaves where you read.11:29
bechameliirc chouchdb save the both version of the document and flag them as duplicates11:30
paepkebechamel, yes. thats right.11:31
paepkeso its up to the application to solve this kind of issue11:31
paepkeeven its just a popup to the user11:32
paepkeare there somewhere attachments used i didn't get already? only attachment module itself and webdav?11:37
-!- sharoon(~sharoon@vpn21.its.manchester.ac.uk) has joined #tryton11:43
cedkpaepke: I don't see any advantage for using NoSQL instead of filesystem11:46
paepkecedk, scalability.11:48
cedkpaepke: you can have the same with filesystem11:49
paepkecedk, not that easy. using a clusterfs is horrible11:49
cedkpaepke: by the way, what do you name scaliablity11:49
bechamelpaepke: how many documents do you plan to store ?11:52
paepkecedk, scalability in terms of storage space which could exceed one node.11:52
paepkebechamel, currently not that much. as i stated above i have the problem with the replication.11:52
cedkpaepke: this is easy to fix as you can see Tryton stores document with a tree structure so you can move one or many folder in an other place11:53
cedkpaepke: you can do replication with rsync/unison etc.11:54
paepkecedk, i know how the files were stored in tryton.11:54
paepkecedk, i need the replication based on a field in the application like a boolean "do publish"11:54
paepkecedk, and i have the multi-master situation.11:55
cedkpaepke: so NoSQL will not help you11:56
paepkeanyway. i see the document based database as a filesystem on steroids. for example appending additional fields on it11:56
paepkecedk, why don't you think it will not help me?11:56
cedkpaepke: because it doesn't solve your issue11:57
cedkpaepke: which is an issue that have no clean solution11:57
bechamelpaepke: does both sites works on the same documents ? or each site just generates their documents ?11:59
paepkecedk, i know its not that easy what i'm planning to do.11:59
paepkecedk, generate their documents. but the should appear on both sides.12:00
paepkebechamel...12:00
paepkebechamel, think of a upload-download portal.12:00
cedkpaepke: why not having only one source12:02
bechamelso what about add a bollean field (like to_be_synced) on the attachement table and when the connection is up between the sites, just send the flagged documents ?12:02
paepkecedk, anyway. isn't nosql an additional storage engine which can live next to filesystem based storage? is see it like having an additonal sql database. postgre fits the needs pretty good. but mysql is out there, too12:02
cedkNoSQL is not an additional SQL database12:03
paepkecedk, cause there is an slow unreliable connection between the webserver and the tryton base.12:03
paepkebechamel, i have to take care of the uploaded documents, too on the other side. i have to develop an additional functions which take care of all replication which could happen (broken connection, is there already a version, ...) which is all integrated in couchdb.12:05
paepkecedk, yes,NoSQL its not SQL. i see it as a "competitor" to file based storage. of course not to SQL12:06
paepkecedk, sorry for the misleading use of words.12:06
cedkpaepke: in fact I think you must not have colision, just use an append only scenario12:07
yangoon"nosql" (the community now translates it mostly with "not only sql")  ;)12:07
cedkyangoon: the current filesystem mechanism is a NoSQL12:07
paepkecedk, so why not supporting an additional NoSQL storage next to the current file system storage?12:10
cedkpaepke: but I don't see the purpose12:11
paepkeis there an purpose to have mysql next to postgres?12:11
cedkpaepke: they are both SQL server12:13
cedkpaepke: NoSQL is not a standard12:14
cedkpaepke: so how can you make a generic behavior12:14
paepkecedk, I know that NoSQL is a broad range methods of storing information.12:15
paepkecedk, i'm primary talking about schemaless document storage, which is provided by mongodb or couchdb. I assumed its clear as we speak about storing files. my appologies for that.12:16
bechamelpaepke: IMO the "broken connection" is not a big problem, just put a try-except and retry later (or just forget it if the document upload is in a cron), the "there is already a version" can be 1) ignored (the document is just overwirtten) 2) taken into account: the incoming document is stored appart and the user is asked to compare them (something you need to handle anyway) and choose the good one12:18
paepkecedk, additionally (not my primary goal of this discussion)is  one of the interesting features of having a couchdb storag is the possibility to take the documents with you just by cloning the couchdb to youre notebook.12:19
-!- eLBati(~elbati@94.167.7.222) has joined #tryton12:22
paepkebechamel, yes, thats a good point with using the cron. that were my first ideas about that project.12:22
paepkebechamel, but after my studies, i remembered couchdb as a solution. and now i'm discussing here my ideas :-)12:23
paepkebechamel, and its still one of my options.12:26
bechamelthe main advantage I see for couchdb is that it's distributed12:27
bechamelbut I read the couchdb doc and it seems that what they call distributed is actually replicated, I talk about distributed="one set of document that span several computers" (sharding?)12:32
paepkebechamel, sharding is possible, too.12:32
bechamelpaepke: ok12:32
paepkebechamel, see http://guide.couchdb.org/editions/1/en/clustering.html12:35
paepkecedk, bechamel. I summarize my options: using a traditional approach writing a cron-script (non-blocking to the save of the attachment) which replicates the file to the other host and vice versa.12:43
paepkecedk, bechamel: an additional option would be to use for example couchdb as backend for attachment which make the replication automagically, but needs the modification of core components of tryton.12:44
bechameljust thinking out loud: with the current fs solution it would be possible to replace top-level local directory with mount point and thus "shard" the documents12:45
paepkecedk, you don't see any advantages having multiple backends for file storage. like having multiple backends for sql storage?12:46
paepkebechamel, yes, you are right with that sharding on top of mount points. it would even work on windows.12:47
yangoonbechamel: I think your proposal is a very monolithic "shard"12:48
bechamelyangoon: hence the quotes :)12:49
paepkeyangoon, bechamel: with couchdb you could shard at field level. for example based on save date, model, whatever. to have kind of multi-tier storage which slower machines on old data.12:49
yangoonbechamel: understood :)12:50
cedkpaepke: you can have any fs you want12:52
cedkpaepke: fs is a standard protocol12:53
paepkejust for the completeness. there is GridFS, a FUSE Backend for Storing attachments inside mongodb.13:10
-!- Okko(~Okko@62.58.29.41) has joined #tryton13:16
-!- digitalsatori(~tony@116.233.249.146) has joined #tryton14:12
-!- tony_(~tony@116.233.242.53) has joined #tryton14:53
-!- tony__(~tony@116.233.242.0) has joined #tryton15:20
-!- digitalsatori(~tony@116.233.240.110) has joined #tryton15:40
-!- digitalsatori(~tony@116.233.240.110) has joined #tryton15:53
-!- pepeu(~manuel@201.155.193.192) has joined #tryton16:00
-!- tony_(~tony@116.233.245.238) has joined #tryton16:01
-!- pheller(~pheller@c1fw234.constantcontact.com) has joined #tryton16:20
-!- tony__(~tony@116.233.244.109) has joined #tryton16:34
-!- paepke(~paepke@p4FEB07FC.dip0.t-ipconnect.de) has joined #tryton16:43
-!- digitalsatori(~tony@116.233.243.197) has joined #tryton16:44
-!- cheche1(cheche@188.85.213.151) has joined #tryton16:54
-!- digitalsatori(~tony@116.233.243.197) has joined #tryton17:13
-!- zodman(~Miranda@200.76.52.125) has joined #tryton17:22
-!- sharoon(~sharoon@vpn21.its.manchester.ac.uk) has joined #tryton17:33
-!- gremly(~gremly@190.147.153.138) has joined #tryton18:30
-!- eLBati(~elbati@94.166.11.169) has joined #tryton19:05
-!- sharoon(~sharoon@vpn85.its.manchester.ac.uk) has joined #tryton19:19
-!- enlightx(~enlightx@dynamic-adsl-94-34-211-122.clienti.tiscali.it) has joined #tryton19:35
-!- paepke(~paepke@p4FEB07FC.dip0.t-ipconnect.de) has left #tryton19:47
-!- hoRn(~chatzilla@dslb-094-223-211-094.pools.arcor-ip.net) has joined #tryton19:54
hoRnhi all19:55
hoRnim struggling for hours with a small problem19:56
hoRn(overall my learning is fast ; )19:57
hoRni have a model with a many2one-field. this model has a workflow with a lot of states.19:59
hoRnin the first state nothing of the many2one-related model is required, but after changing to a following state i want to set some of them required20:00
hoRncan anybody give me a hint, how to do this: now i raise a user error in a function assigned to the workflow transition, but the user need to serch the required fields in the view20:02
enlightxhoRn: what about "attrs"? you can set the required flag to true by object state20:25
hoRnok - i will take another search ;)20:27
-!- enlightx(~enlightx@dynamic-adsl-94-34-211-122.clienti.tiscali.it) has joined #tryton20:36
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton20:57
sharoonenlightx: there is no attrs in tryton21:04
enlightxsharoon: whoops...wrong channel ;-)21:05
sharoonhoRn:  refer http://hg.tryton.org/hgwebdir.cgi/1.6/modules/account/file/6532a3521264/account.py#l33321:05
hoRni'll take a look21:06
sharoonhoRn: You have to write PYSON expression for what you want21:06
sharoonhoRn: refer http://doc.tryton.org/1.6/trytond/doc/topics/pyson.html21:07
hoRnyes i know21:07
sharoonhoRn: that will help you write the PYSON syntax21:07
hoRnbut the problem is a little bit more confused21:08
hoRnfor example: in sale you can put lines21:08
sharoonhoRn: please explain,21:08
hoRnsharoon: the line has his own definition of required fields - for example the pricel21:09
hoRnyou can not save a sale.line, if no price is set21:10
sharoonhoRn: ok21:10
hoRnsharoon: now think in your own sales.opportunities21:10
hoRnyou have fields in sale.opportunities - required or not21:11
hoRnthe lines are products - with defined requirements21:11
hoRnnothing goes wrong21:11
sharoonok21:11
hoRnbut i will do this: a model similar to sales.oportunities21:12
hoRnbut i do not put products as lines, i have a own model21:13
hoRna hugh form with thausend of inputs21:13
sharoonhoRn: please use pastie for pasting your code, might be easier to understand the problem21:13
hoRnif the customer calls the first time, the telefonist ask something21:14
hoRnafter this the form needs completion, before he can convert it to a state like opportunity21:15
hoRnbut the telefonist need to save the result of the first call - the completion of the lines is only needed, if the parent-object will be converted to another state21:16
hoRnsharoon: i will paste21:17
hoRnhttp://pastie.org/111864421:20
hoRnat line 225 is a strange try of doing that what i want21:21
hoRnwhen i convert teh coatingrequest to an opportunity, i will check, if the coatingrequest.lines are filled in a minimal manner21:26
hoRnfinally it could be broken by design ;(21:27
sharoonhoRn: first of all it is advised to use browse in the code rather than read (unless not avoidable)21:34
hoRnok21:35
sharoonhoRn: line 244 etc are not pythonic at all21:35
hoRnthat was only a short idea -21:36
hoRnsharoon: a short test - written in php ;)21:38
sharoonhoRn: what is the problem u r facing?21:40
hoRnsharoon: i was lookin for a possibility to set fields required in the lines if the 'parent' changes the state21:41
sharoonhoRn: http://hg.tryton.org/hgwebdir.cgi/1.6/modules/sale/file/0b436b131d56/sale.py#l96121:42
hoRnsharoon: can i do a pyson statement against the value of a _parent.xxx field?21:44
sharoonhoRn: yes21:44
sharoonhoRn: like http://hg.tryton.org/hgwebdir.cgi/1.6/modules/sale/file/0b436b131d56/sale.py#l96321:44
hoRnhoRn: f.. - i tried this before - with no luck. i will go to do another attempt21:46
hoRnsharoon: 'required': Equall(Eval('_parent_sale.party'),'someone') ?21:48
sharoonhoRn: should work21:53
hoRnsharoon: ok - thank you - i will give it a try21:53
sharoonhoRn: if u need to see how client treats it, check record.py in tryton/gui/window/view_form/model21:55
hoRnsharoon: ok21:55
-!- Okko(~Okko@dhcp-077-251-140-095.chello.nl) has joined #tryton21:55
hoRnsharron: i don#t get it - to tired ; thanks so long22:09
sharoonhoRn: http://hg.tryton.org/hgwebdir.cgi/1.6/tryton/file/628d9539e86c/tryton/gui/window/view_form/model/record.py#l34722:15
hoRn:/22:17
hoRnsharoon: a last try - than beer22:18
sharoonhoRn: good luck22:18
hoRnsharoon: thnaks22:18
-!- zodman(~zodman@foresight/developer/zodman) has joined #tryton22:32
-!- Okko(~Okko@dhcp-077-251-140-095.chello.nl) has joined #tryton22:35
-!- bechamel(~user@2001:6f8:3aa:0:1e4b:d6ff:fe60:a002) has joined #tryton22:49
zodmandudes tryton development is easy !!!!22:57
zodmanxD22:57
zodmangood work!22:57
-!- sharoon(~sharoon@vpn59.its.manchester.ac.uk) has joined #tryton23:28
-!- pheller(~pheller@2002:ad30:d8c3:0:fa1e:dfff:fee6:aabf) has joined #tryton23:40

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