This question has been flagged
1 Reply
3449 Views

Dear community,

I have come up with a ORM method to compute the ongoing sale + credit amount of partners grouped by same register code (aka siren character). However the method is awfully slow and causes performance issues. 

In order to fix the method I have tried translating the ORM method into a SQL query (for greater perfomance). Testing shows that the SQL query performs even worse than the ORM method.

I expect this shouldn't be the case..so... what am I doing wrong ?

class ResPartner(models.Model):
    _inherit = 'res.partner'

    ongoing_amount = fields.Float(
        string='Encours HT',
        help='Le montant total encours hors taxes',
        compute='_get_ongoing_amount',
        store=False,
    )

ORM Method:

    @api.one
    @api.depends('siren')
    def _get_ongoing_amount(self):
        lines_invoice = self.env['account.invoice.line'].search([
            ('invoice_id.state','in',['open']),
            ('partner_id.siren','=',self.siren),
            ('partner_id.siren','!=',False),
            ])

        lines_order = self.env['sale.order.line'].search([
            ('order_partner_id.siren','=',self.siren),
            ('order_partner_id.siren','!=',False),
            ('qty_invoiced','=','0'),
            ('state','in',['sale']),
            ('cash','=',False)
            ])
        self.ongoing_amount = sum(line.price_subtotal for line in lines_invoice) \
        + sum(line.price_subtotal for line in lines_order)

SQL method :

    @api.one
    @api.depends('siren')
    def _get_ongoing_amount(self):
        # make sure param doesn't get to false
        param = self.siren
        if not param:
            param = '999999999'
        sum_lines_invoice = self._cr.execute("""
            SELECT SUM(price_subtotal)
            FROM account_invoice_line
            FULL JOIN account_invoice so ON (state=so.state)
            FULL JOIN res_partner res ON (siren=res.siren)
            WHERE siren = %s
            AND state IN ('open')""", (param,))
        sum_lines_invoice = self._cr.fetchone()[0] or 0.0

        sum_lines_order = self._cr.execute("""
            SELECT SUM(price_subtotal)
            FROM sale_order_line
            WHERE siren = %s
            AND qty_invoiced = '0'
            AND state IN ('sale')
            AND cash IS FALSE""", (param,))
        sum_lines_order = self._cr.fetchone()[0] or 0.0
        
        self.ongoing_amount = sum_lines_invoice + sum_lines_order
Avatar
Discard
Best Answer

Just a few notes regarding:

  1. Replace your @api.one with @api.multi. Beside @api.one is a deprecated decorator, it is also slower in case of multi records. In particular, if you show the field ongoing_amount in kanban or list view, your method would be launched as many times as many records are shown (usually 80) and all checks would be 80 times more frequent (e.g. the check for non-existing param). If you are sure you require only a single record, put self.ensure_one() at the beginning of your @api.multi method.

  2. When you avoid using ORM, you loose some critical features including security rights. For example, in your case a simple user would see sum by all records by all companies, even though he/she doesn't have right for those. So, just take that in account.

  3. I would also offer to keep 'siren' field right in account.invoice.line as a stored computed field depending on a partner siren (perhaps, also the invoice line state). Although it contradicts sql tables normalizing, it would let you avoid joining the tables which, I guess, is quite resource-consuming. Besides, in my opinion it is better to firstly search by siren and than by state, since the latter records should be represented by a bigger number.

As for the point that SQL is slower than ORM. I can't see here the real reason for that (although 'full join' leads to a few doubts). Perhaps, it is because of a used decorator, or since ORM implied SQL queries are optimized in comparison to your statements. Just as a hint: have a look at _search, search and search_count methods right in the Odoo core. Perhaps, it would lead you to some insights. Besides, if you consider migration to odoo 11 or 12: their cashing is optimized.

Avatar
Discard