1. Mailing Lists
  2. Accounting
  3. Re: [15042] Reasoning on missing parents in analytic accounts

Accounting mailing list archives

accounting@odoo-community.org

Browse archives

Re: [15042] Reasoning on missing parents in analytic accounts

Re: [15042] Reasoning on missing parents in analytic accounts

Avatar

Re: [15042] Reasoning on missing parents in analytic accounts

by
InitOS GmbH, Frederik Kramer
- 17/02/2017 17:34:13 
Hi Nhomar, 

find my answer inline

Am Freitag, den 17.02.2017, 16:08 +0000 schrieb Nhomar Hernandez
[Vauxoo]:
> 
> On Fri, Feb 17, 2017 at 9:38 AM, Frederik Kramer <frederik.kramer@ini
> tos.com> wrote:
> > Haha Fabiaens reasoning about that is funny. At the very end of the
> > day it boils down to the fact that Odoo ORM is just too
> > imperformant to  allow massive joins on accounting every one and a
> > while and doesn't make good use of the query analyzer and
> > performance tweaks to the database either. 
> Well..
> 
> I thought the same in the past, but when you see how huge systems are
> moving to NoSQL, and you measure the performance 1by1 (I did it just
> to start a huge threas fighting this) I realize the numbers gave the
> reason to Fabien.
> 
> We did the performance improvement using the proper DB management via
> pure SQL [1].
> 
> That was why we were conceptually really pissed off with the change,
> but that situation had several problems.
> 
> 1.- The sql is not AT ALL easy to maintain, better python.
> 2.- There is a lot of good python tools to analyze really efficiently
> data (Pandas for example) [2].
> 3.- It acelerates the improvements in other areas in odoo accounting
> (more functional ones than technical ones).
> 
> Then we measured, and we lost.... What I recommend to you is make a
> real performance measure (not conceptually, prepare a tes
> environment), and measure the situation, variables like:
> 
> 1.- Report generation.
> 2.- Report creation time.
> 3.- User engagement.
> 4.- Consistency in data.
> 6.- Time and materials expend in fix data.

We did such a thing in that we replaced part of the ORM to store data
in Hadoop (whereas Hadoop is not necessarily the best choice for the
workload we discuss here) and yes, the real problem stems from front-
end processing of the data in the web client, at least for day to day
use.

But yes i'd like to really do a module that does more like what
transaction ST03 or ST03n (for SAP HANA) in SAP does, i.e. an holistic
system measurement.

Kind regards

Frederik

> 
> You will see it was not that crazy.
> 
> Obviously... YES, in v9.0 several changes pissed me off, but they
> were not related to data model, they were related to incorrect
> debugging and maturity time in our side also.
> 
> Regards.
> 
> 
> [1] https://code.launchpad.net/~openerp-community/openobject-addons/t
> runk-btree_compute-vauxoo/+merge/127138
> [2] http://pandas.pydata.org/
> 
> Nhomar Hernandez
> CEO Vauxoo.
> Site: http://vauxoo.com
> Twitter: @nhomar
> Blog: http://nhomar.com
> Github User: https://github.com/nhomar
> Odoo Gold Partner
> Skype: nhomar00 (Envia mail previo no lo superviso siempre).
> HangOut: nhomar@vauxoo.com
> Móvil Venezuela:
> +58 4144110269
> Móvil México:
> +52 1 4773933942
> _______________________________________________
> Mailing-List: http://odoo-community.org/groups/accounting-28
> Post to: mailto:accounting@odoo-community.org
> Unsubscribe: http://odoo-community.org/groups?unsubscribe
-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer
        
initOS GmbH
An der Eisenbahn 1
21224 Rosengarten
        
Phone:  +49 4105 56156-12
Fax:    +49 4105 56156-10
Mobil:  +49 179 3901819
        
Email: frederik.kramer@initos.com
Web:   www.initos.com
        
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

Reference