domain restriction in osv_memory models

Bug #821041 reported by ViktorNagy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Server (MOVED TO GITHUB)
Invalid
Undecided
Unassigned

Bug Description

Hi

I have a return statement of the form:

    return {
            'name':_("Products to Process"),
            'view_mode': 'tree',
            'view_id': False,
            'view_type': 'tree',
            'res_model': 'mrp.component',
            'res_ids': new_ids,
            'type': 'ir.actions.act_window',
            'nodestroy': True,
            'target': 'new',
            'domain': '[]',
            'context': context
        }

where mrp.component is an osv_memory object
changing the domain restriction to something meaningful (e.g. [("parent_id", "=", None)] gives an error as it uses the search method of the orm class instead of orm_memory
(of course, I've overwritten the orm_memory::search method as it would always return all the keys)

[2011-08-04 19:33:28,665][helti_test] ERROR:web-services:Uncaught exception
Traceback (most recent call last):
  File "/home/akasha/versioning/bzr/openerp-6/server/bin/osv/osv.py", line 122, in wrapper
    return f(self, dbname, *args, **kwargs)
  File "/home/akasha/versioning/bzr/openerp-6/server/bin/osv/osv.py", line 176, in execute
    res = self.execute_cr(cr, uid, obj, method, *args, **kw)
  File "/home/akasha/versioning/bzr/openerp-6/server/bin/osv/osv.py", line 167, in execute_cr
    return getattr(object, method)(cr, uid, *args, **kw)
  File "/home/akasha/.virtualenvs/openerp6/lib/python2.6/site-packages/openerp-server/addons/mrp_components/mrp_components.py", line 31, in search
    return super(mrp_component, self).search(cr, uid, args, offset, limit, order, context, count)
  File "/home/akasha/versioning/bzr/openerp-6/server/bin/osv/orm.py", line 1745, in search
    return self._search(cr, user, args, offset=offset, limit=limit, order=order, context=context, count=count)
  File "/home/akasha/versioning/bzr/openerp-6/server/bin/osv/orm.py", line 2073, in _search
    val = eval('data[arg[0]]'+'==' +' arg[2]', locals())
  File "/home/akasha/versioning/bzr/openerp-6/server/bin/tools/safe_eval.py", line 284, in safe_eval
    return eval(test_expr(expr,_SAFE_OPCODES, mode=mode), globals_dict, locals_dict)
  File "", line 1, in <module>
KeyError: 'parent_id'

I'm using the 6.0 branch of openobject-server

Revision history for this message
Naresh(OpenERP) (nch-openerp) wrote :

Hello,

The osv_memory will soon be disappearing from the server, it will be replaced by osv with just some boolean information to know that it should be cleaned from the db from time to time so these will work as normal osv but with short life span.

Thanks

Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

Hello,

As Naresh explained, osv_memory are being phased out for OpenERP 6.1, which should solve a lot of issues like yours, and also makes osv_memory irrelevant in our current trunk.
We could consider patching it in the 6.0 stable branch if we found out a critical issue that would impact many customers in production, but otherwise our stable policy prevents any kind of "low priority" or "improvement" from landing there.

That said, we can help you identify the cause of your issue and determine if this could qualify as a critical issue. For that, we'll need to be able to reproduce the bug, so you will need to provide more details, and perhaps a sample module that triggers it.
For example:
- You say that it "gives an error as it uses the search method of the orm class instead of orm_memory". I'd like to run your code and see how that's possible, because it makes no sense with our usual class hierarchy. If 'mrp.component' is a subclass of 'osv.osv_memory' there is no way the osv.osv.search() method should be called, unless you're mixing both osv and osv_memory in the class tree.
- You say "of course, I've overwritten the orm_memory::search method as it would always return all the keys". Based on your traceback you're still relying on the super()._search() method, so what did you change? Perhaps there was one kind of domain that you needed to use and was not supported by osv_memory's _search() method? Can you be more specific?
- Finally, your traceback shows that the osv_memory rows you are querying do not have a cached "parent_id" column value. Can you perhaps investigate the contents of the osv_memory cache and see how that is possible?

I hope this helps...

Changed in openobject-server:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for OpenERP Server because there has been no activity for 60 days.]

Changed in openobject-server:
status: Incomplete → Expired
Revision history for this message
Amit Parik (amit-parik) wrote :

Hello,

Would you please check this again with latest updated code.

Currently I am closing this issue and if you still face the problem then you can reopen this with more information.

Thanks

Changed in openobject-server:
status: Expired → Invalid
Revision history for this message
ViktorNagy (viktor-nagy) wrote : Re: [Bug 821041] Re: domain restriction in osv_memory models

you mean the trunk/6.1 version or the 6.0.x version code?

On Tue, Oct 11, 2011 at 6:53 AM, Amit Parik (OpenERP) <email address hidden>wrote:

> Hello,
>
> Would you please check this again with latest updated code.
>
> Currently I am closing this issue and if you still face the problem then
> you can reopen this with more information.
>
> Thanks
>
>
> ** Changed in: openobject-server
> Status: Expired => Invalid
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/821041
>
> Title:
> domain restriction in osv_memory models
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-server/+bug/821041/+subscriptions
>

Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

@ViktorNagy: The refactoring in the trunk/6.1 for removing osv_memory has landed, so if you try again on trunk (with a new database) you should not have this kind of issue anymore. For 6.0, we don't plan on changing it, as explained in my comment #2 for why we consider this invalid. We can consider this issue closed now, unless you have further feedback about it.
Thanks!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.