IRC logs of #tryton for Wednesday, 2011-11-09 #tryton log beginning Wed Nov 9 00:00:01 CET 2011
zxq9Is it possible to display field data from multiple models in the same tree view?06:14
zxq9Specifically, using a many2many junction table, I need the junctions/references to carry some information also.06:16
zxq9Like a "parents" table and a "children" table, connected by a many2many junction table which can say if the child relationship to a parent is "stepchild" or "daughter" or "ward" or whatever.06:17
zxq9In the tree view and the form within the parent form, I want to be able to display the child's name and the relationship type.06:18
zxq9Oops. The 2.2 documentation still has notebook, tabpos listed as working.06:29
zxq9How to display fields from several modules/models in a single form or tree view?10:25
zxq9Specifically, I need to include information about a relationship from a junction table in a form. So people can set things like type of family relationship (mother, daughter, etc.) and similar data.10:34
zxq9I can create the fields in a many2many junction table, but I can't seem to display or manipulate the information from a form in the client. ?10:35
udonozxq9: you can 'carry' a finit set of fields from other models to a model with fields.Function.10:55
zxq9Maybe this is what I need. Seems strange you can't just display a view that represents a multiple join, though.10:56
udonozxq9: when you create views for the many2many junction table, all fields used there can be shown.10:56
udonozxq9: It is hard for me to answer this kind of questions without seen the code.10:58
udonoThis I do not understand "Seems strange you can't just display a view that represents a multiple join"10:58
zxq9For example, if I want to make a tree view that has information from 'parents' table, then an information field from the junction table 'parent-child' like "daughter" or "step-son", then information from the 'children' table in one tree view.11:00
zxq9That joins three tables in a single tree view. This is what I need to do, to define or categorize the relationship inside the junction table.11:01
udonozxq9: For this kind of views I would use Function fields. But this depends on the exact model design and on how many data needed to be retrieved with function fields. Function fields tend to be slow on big data amount or complex calculations, specially in tree views.11:11
zxq9That's sort of strange -- this is a very basic database function (definition/categorization of many2many relationships). I wonder why this is so slow/difficult in Tryton?11:17
zxq9It seems like there must be some other way. (?.?)11:17
zxq9Anyway, to get things working I'll play with function fields. Thanks for your help, Udo!11:18
bechamelzxq9: you can build a model on top of a custom db query, like the HoursEmployee model in timesheet/line.py11:31
zxq9bechamel: Seems odd that this is necessary (Tryton is full of features, but not this one?), but it may be the best way. Thank you for the reference!11:44
udonozxq9: as said earlier, without code example it is hard to help.12:28
zxq9udono: OK, I have a very simple example:
zxq9In this case, the model drivers.vehicle has a field called 'purpose' which defines the relationship between the driver and vehicle.12:40
zxq9How can I display this in the driver form and tree so that the user can set and use this information? Does this require a custom SQL query or a Function() type field?12:41
udonozxq9: line 30-3313:04
zxq9There is no "name" field in drivers.vehicle, it is referenced from vehicle.vehicle.13:17
zxq9Adding the purpose field to the xml doesn't change anything. I'll try adding a name field to drivers.vehicle and see if that works.13:18
zxq9Adding a name field to drivers.vehicle, and adding the "name" and "purpose" fields to the XML does not change anything on the tree view or the form.13:20
zxq9Revised example (also corrected for plural names):
zxq9This example does not show me "purpose" from driver.vehicle -- which is what I need to be able to do. I feel like I'm just missing something very simple here again that is not well documented (but probably works fine).13:24
zxq9Hi sharoon.13:26
udonozxq9: did you update the database for the module? Did you try it on a fresh database?13:26
udonozxq9: Sure you did try it on a fresh database?13:27
zxq9I'll do it (again) just now.13:27
bechamelzxq9: in your xml there are no view for driver.vehicle13:28
udonobechamel: line 29-3113:29
bechameloh yes, sorry13:31
zxq9You mean a ir.ui.view definition?13:31
bechamelzxq9: yes but I didn't read correctly the xml13:33
bechamelzxq9: the problem is that m2m doesnt works like that13:36
zxq9m2m doesn't permit reference definitions?13:36
bechamelzxq9: when you put the field vehicule in the view of Driver, the client will show you the content of the Vehicule model13:37
bechamelnot the content of "Driver - Vehicule"13:37
zxq9Is there no way to access junction table definition data?13:37
bechamelzxq9: you must use a one2many13:38
zxq9As in, there is no way to add data to the reference itself?13:38
zxq9That is not possible for a case like this, though.13:38
bechamelzxq9: keep your model as they are13:39
zxq9For example, the ferry driver of a crane truck is not the same person as the crane pilot on the work site. They are both assigned the same vehicle.13:39
bechameljust change the defintion of the vehicule field13:39
udonozxq9: you can use a one2many with widget="many2many"13:39
bechameludono: I don't think this will give the correct behaviour13:40
bechamelzxq9: udono: here it is a real o2m13:40
zxq9And this will allow multiple vehicles driven by multiple people categorized by purpose?13:40
bechamelone "driver" - many "driver vehicule"13:40
zxq9How is the reverse relationship defined, then? How do I find how many drivers touch a single vehicle?13:41
bechamelzxq9: yes the tables will stay  exactly the same13:41
bechamelit's just the display that will change13:41
zxq9let me try this.13:42
bechamelwhen tryton show a m2m field it's the "target" table that is displayed, not the intermediate one that support the relation13:42
bechameland here you want to show the relation table13:42
zxq9ok. I think I see what you mean. I'm still thinking like making SQL queries.13:43
cedkthere is no mystery, you must use a One2Many13:43
zxq9From driver.driver to driver.vehicle?13:44
bechamelzxq9: yes13:45
zxq9To handle the opposite relationship do I need to set a One2Many from vehicle.vehicle (as in driver = fields.One2Many('driver.vehicle', 'driver', 'Drivers')?)13:46
nicoejust make a o2m relation between your driver and the relation table13:52
nicoeis 'driver.vehicle' the relation table ?13:53
zxq9I'm playing with it now.13:53
nicoethen it's ok13:53
zxq9I think I understand this now. Still unsure about the reverse relationship (viewing the relationships from the vehicle side).13:54
zxq9Thanks for your patience, everyone. You've really helped me a lot here.13:54
zxq9Out of curiosity, inside the actual database did Tryton create more than 3 tables to handle this relationship? Or just exactly 3?13:58
udonozxq9: check the database yourself. You can try with psql or pgadmin3.14:01
zxq9I will14:01
sharoonzxq9: hi14:51
sharooncedk: if you think search would be a relevant topic, we could discuss this at the workshop15:11
sharooncedk: i have tried the sphinx integration with tryton and I don't think sphinx is a right fit for us or for any application with an ORM and large set of data15:11
sharooncedk: for example it can do delta updates only for SQL data sources15:12
sharooncedk: i think SOLR is a better candidate and i could make  a POC by then15:12
bechamelsharoon: there is also xapian, which doesn't have this delta problem15:21
bechameland it's easier to deploy, as it's just a library15:22
sharoonbechamel: ok, never used it15:22
sharoonbechamel: i would really prefer a separate server which is independent of tryton and is realtime for the purpose, however we could discuss the pros and cons15:23
bechamelsharoon: afais xapian is "realtime" if realtime means that it's not needed to reconstruct the index periodically15:25
sharoonbechamel: thats what i meant by realtime15:25
cedksharoon: xapian is activated on roundup16:01
sharooncedk: won, thats cool, but we have around 2 k records right ?16:01
sharooncedk: how do you find the performance ?16:01
sharooncedk: and is it schema less ?16:01
cedksharoon: don't know it yet enough16:02
bechamelsharoon: cedk:
sharoonbechamel: will not fit our needs :( Xapian uses unsigned 32-bit ints for document ids16:04
cedksharoon: what is used in PostgreSQL?16:05
bechamel"Xapian uses unsigned 32-bit ints for document ids, so you're limited to just over 4 billion" -> 4 billion is not enough ?16:06
cedkbechamel: what is the limit of pg16:06
sharooncedk: not about 32 bit IDS, we use strings in some cases as IDs16:07
cedksharoon: not in Tryton16:07
sharooncedk: the nosql database especially don't come with anything like an integer id16:07
sharooncedk: you are right, not in tryton16:07
bechamelsharoon: cedk: I think those 32-bit int are internal to xapian, no ?16:08
sharoonbechamel: i think just like sphinx, it should be an unique document identifier and used also in updates of existing records16:09
bechamelcedk: in postres an integer (what we use for the id col) is 4 bytes (32 bits), see
cedkbechamel: ok so it is compatible :-)16:25
bechamelcedk: I think this is wrong to compare those ids with pg ids16:26
bechamelcedk: xapian is used to index websites, pdf's and mails, and those stuff doesn't have any integer id, but an url16:27
bechamelso xapian must provide a way to store an external identifier like an url16:27
cedkbechamel: no, the issue is that xapian should be able to manage as much as postgresql can have of records16:29
bechamelcedk: if it was a problem one can imagine to use several xapian dbs16:32
bechamelbut maybe we will create several db anyway (one per table)16:33
cedkbechamel: no because we must index at a least one table per index16:33
bechamelcedk: ?16:35
cedkbechamel: the goal of xapian will be to replace search with "ilike"16:36
cedkbechamel: so you must index at least all records of a table for a columns16:36
bechamelcedk: yes but we can create one xapian db per tryton model16:38
cedkbechamel: yes so the goal is to be able  to index all the records of a table16:38
bechamelsharoon, cedk: by the way, it shouldn't be difficult to support several search engine, just like we support several rdbms16:42
cedkbechamel: not sure because there is no general query language as there is SQL16:43
sharoonbechamel: i support that too, i think16:43
sharooncedk: I think the goal should be just define a pluggable search APIs where the default is the standard search of tryton using postgres alone16:44
sharooncedk: currently this is difficult to do16:44
cedksharoon, bechamel: I don't think it is doable16:53
cedkor it will reduce the performence16:53
sharooncedk: i have a proposal for the same without affecting performance significantly16:54
sharooncedk: we can discuss when we are there16:54
cedkI even think that once there is a good integration, xapian will be a required dependency16:55
bechamelcedk: there are no standard for full text search, but we don't complex stuff16:57
bechamelcedk: just the equivalent of "ilike *word*"16:57
-!- pjstevns( has left #tryton16:58
cedkbechamel: no I think we can do more16:58

Generated by 2.11.0 by Marius Gedminas - find it at!