On Wednesday 09 March 2011, you wrote: > Hello XRG, > > Yes it's good that the GTK client warn's the developer about the duplicate > IDS and to fix the search method defined. I tried the fix with just a > simple example I overridden the search method of Sale_order and returned > the ID'S as [IDS] + [IDS] and there was no change. the duplicated Ids were > shown by the client. > > BTW your FIX will not allow to do so because you are comparing the Instance > of 'Model Record' i.e by writing "if l in self.lst:" here 'l' is the > instance. So this will always be False because each search will rebuild > the Model Record with the IDS returned in-spite of their duplication. I > think you should compare them through their ID. > > > Let me know If I am missing something. > At my case, the problem (OOM) occured when I had those IDs listed in a _groupped_ list and actually when the duplicates were next to each other like res = obj.search() res => [ 45, 67, 140, 140, 153]
the bug is that (perhaps due to widget/model/group.py:416, widget/view/list.py:196) the exact same ModelRecord object appears twice in the list (list_record.lst ). Then, at list.py:315:on_iter_next(2) returns the lst[3] element. But, that, is equivalent to lst[2], and so on_iter_next(3) will again return lst[3] == lst[2]. And that's an endless loop. If, as you say, we insert different ModelRecord objects of the same record ids, the problem won't occur. Still, listing them many times at the same list is a logical error for the user (imagine selecting them both and applying an action). My patch, hopefully, fixed the extreme case (of the groupped list) in a way with least side-effects. -- You received this bug notification because you are a member of OpenERP sa GTK client R&D, which is a bug assignee. https://bugs.launchpad.net/bugs/728275 Title: view/list: Fix handling of duplicate IDs from search() Status in OpenERP GTK Client: Confirmed Bug description: A /broken/ model (report.membership) at the server happened to return duplicate ids of records (using a badly migrated dataset, too). This propagated to the Gtk client, which inserted the ids at duplicate positions of the list view. When iterating over them, the client was trapped into an OOM, which is critical and DoSes the host desktop. The server should never have done that, agreed. But, the network principle says "send clean, accept garbage", so we'd better not die if such data ever come again. Gently logging the case was the way to go. If we raise an exception (tried that), the Gtk framework will come back asking for the list item again, which ends up in an ugly full-load (but not lethal) of the client (and a few more calls to the server). _______________________________________________ Mailing list: https://launchpad.net/~openerp-dev-gtk Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-dev-gtk More help : https://help.launchpad.net/ListHelp
