openerp-india team mailing list archive

[Willow IT's Code Repository Admin <929358@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

We have a module called "w_configurator" which is an extension of, among
other things, sales.  It is currently being used in OpenERP v6.0, and we
are testing it under v6.1.

It has a class which uses:

    class WC_Sale_Order_Line(osv.osv):
        _inherit = "sale.order.line"

and inside this class, it overrides create.  Inside the create method,
we use:

    super(WC_Sale_Order_Line,self).create(.....

This gave us some problems, and after a lot of testing we found the
following.

    self.pool.get('sale.order.line').create(...

was calling the correct method, but the "super" call was not calling the
super, rather it was calling itself again!

Further testing revealed that

    self.__class__.__mro__

had the following value

    (<class 'openerp.osv.orm.sale.order.line'>,
     <class 'openerp.addons.w_configurator.sale.sale.WC_Sale_Order_Line'>,
     <class 'openerp.osv.orm.sale.order.line'>,
     <class 'w_configurator.sale.sale.WC_Sale_Order_Line'>,
     <class 'openerp.osv.orm.sale.order.line'>,
     <class 'openerp.addons.sale.edi.sale_order.sale_order_line'>,
     <class 'openerp.addons.sale.sale.sale_order_line'>,
     <class 'openerp.osv.orm.Model'>,
     <class 'openerp.osv.orm.BaseModel'>,
     <class 'edi.models.edi.EDIMixin'>,
     <type 'object'>)

Dropping the database, and installing from scratch did not fix the
problem.  However, renaming the module and installing seemed to work,
first time only (dropping the database, and reinstalling the renamed
module seemed to cause it to fail again).  There was no foolproof way we
could find of installing the module to either guarantee it would fall
over or guarantee it would work, other than to say that once it fell
over, we could not get it to work again using the same module name, no
matter what sequence we did database dropping, server restarting, or
anything else we thought might influence the result.  When the module
worked,

    self.__class__.__mro___

had the following value

    (<class 'openerp.osv.orm.sale.order.line'>,
     <class 'openerp.addons.w_configurator.sale.sale.WC_Sale_Order_Line'>,
     <class 'openerp.osv.orm.sale.order.line'>,
     <class 'openerp.addons.sale.edi.sale_order.sale_order_line'>,
     <class 'openerp.addons.sale.sale.sale_order_line'>,
     <class 'openerp.osv.orm.Model'>,
     <class 'openerp.osv.orm.BaseModel'>,
     <class 'edi.models.edi.EDIMixin'>,
     <type 'object'>)

What stood out to me, was that <class
'w_configurator.sale.sale.WC_Sale_Order_Line'> entry in the "corrupt"
__mro__ is in fact a repeat of <class
'openerp.addons.w_configurator.sale.sale.WC_Sale_Order_Line'>, but
lesser qualified.

When this lesser qualified class is not in the __mro__, everything
works.  Also, this lesser qualified class stands out compared to the
rest of the classes listed, due to the fact that it is not fully
qualified.

(It is worth noting, that in both cases, printing

    WC_Sale_Order_Line.__mro__

was the same:

    (<class 'openerp.addons.w_configurator3.sale.sale.WC_Sale_Order_Line'>,
     <class 'openerp.osv.orm.Model'>,
     <class 'openerp.osv.orm.BaseModel'>,
     <type 'object'>)


We have lost many days already, just getting to this point, so any help would be greatly appreciated.

** Affects: openobject-server
     Importance: Undecided
         Status: New


** Tags: method.resolution.order mro super

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/929358

Title:
  OpenERP v6.1 module testing, and possible corrupt __mro__ (method
  resolution order)

Status in OpenERP Server:
  New

Bug description:
  We have a module called "w_configurator" which is an extension of,
  among other things, sales.  It is currently being used in OpenERP
  v6.0, and we are testing it under v6.1.

  It has a class which uses:

      class WC_Sale_Order_Line(osv.osv):
          _inherit = "sale.order.line"

  and inside this class, it overrides create.  Inside the create method,
  we use:

      super(WC_Sale_Order_Line,self).create(.....

  This gave us some problems, and after a lot of testing we found the
  following.

      self.pool.get('sale.order.line').create(...

  was calling the correct method, but the "super" call was not calling
  the super, rather it was calling itself again!

  Further testing revealed that

      self.__class__.__mro__

  had the following value

      (<class 'openerp.osv.orm.sale.order.line'>,
       <class 'openerp.addons.w_configurator.sale.sale.WC_Sale_Order_Line'>,
       <class 'openerp.osv.orm.sale.order.line'>,
       <class 'w_configurator.sale.sale.WC_Sale_Order_Line'>,
       <class 'openerp.osv.orm.sale.order.line'>,
       <class 'openerp.addons.sale.edi.sale_order.sale_order_line'>,
       <class 'openerp.addons.sale.sale.sale_order_line'>,
       <class 'openerp.osv.orm.Model'>,
       <class 'openerp.osv.orm.BaseModel'>,
       <class 'edi.models.edi.EDIMixin'>,
       <type 'object'>)

  Dropping the database, and installing from scratch did not fix the
  problem.  However, renaming the module and installing seemed to work,
  first time only (dropping the database, and reinstalling the renamed
  module seemed to cause it to fail again).  There was no foolproof way
  we could find of installing the module to either guarantee it would
  fall over or guarantee it would work, other than to say that once it
  fell over, we could not get it to work again using the same module
  name, no matter what sequence we did database dropping, server
  restarting, or anything else we thought might influence the result.
  When the module worked,

      self.__class__.__mro___

  had the following value

      (<class 'openerp.osv.orm.sale.order.line'>,
       <class 'openerp.addons.w_configurator.sale.sale.WC_Sale_Order_Line'>,
       <class 'openerp.osv.orm.sale.order.line'>,
       <class 'openerp.addons.sale.edi.sale_order.sale_order_line'>,
       <class 'openerp.addons.sale.sale.sale_order_line'>,
       <class 'openerp.osv.orm.Model'>,
       <class 'openerp.osv.orm.BaseModel'>,
       <class 'edi.models.edi.EDIMixin'>,
       <type 'object'>)

  What stood out to me, was that <class
  'w_configurator.sale.sale.WC_Sale_Order_Line'> entry in the "corrupt"
  __mro__ is in fact a repeat of <class
  'openerp.addons.w_configurator.sale.sale.WC_Sale_Order_Line'>, but
  lesser qualified.

  When this lesser qualified class is not in the __mro__, everything
  works.  Also, this lesser qualified class stands out compared to the
  rest of the classes listed, due to the fact that it is not fully
  qualified.

  (It is worth noting, that in both cases, printing

      WC_Sale_Order_Line.__mro__

  was the same:

      (<class 'openerp.addons.w_configurator3.sale.sale.WC_Sale_Order_Line'>,
       <class 'openerp.osv.orm.Model'>,
       <class 'openerp.osv.orm.BaseModel'>,
       <type 'object'>)

  
  We have lost many days already, just getting to this point, so any help would be greatly appreciated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/929358/+subscriptions