openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

hello Denis,

generally speaking it's hard to believe merging is the solution.

Random things you can do in your case:

Sometimes you can declare a fake dependency like A < B even if it's not
true, but just to fix the load order. This is a hack, but probably better
than going for spaghetti code at large.

Sometimes if A and B both override some method and that loading order ca be
a problem. Sometimes, creating yet a new module C that both A and B will
depend on, with a proper abstraction in C can fix the problem.

Sometimes, if a core method is so badly designed that really it's
impossible to extend it multiple times, then consider that some base module
"monkey patch" the offensive bad method and transforms it into a decent
citizens for overriders. <subliminal_message> You know it's why I mad at
trying to get these kind of no-brainer changes in the core before the
release https://github.com/odoo/odoo/pull/915/files </subliminal_message>
<subliminal_message> and hell that one two
https://github.com/odoo/odoo/pull/913 </subliminal_message>

If monkey patching is too hard or if there is indertermination between
modules order that would introduce the monkey patch, well it's even less
critical to patch the core codebase with surgery patches that you properly
keep under version control so that the core methods get decent to override.
This is a hack, but again, better than going for spaghetti code.

Unit testing the modules is great.
But eventually you can add functional tests in the top level "profile"
module so that you ensure some tests are running with everything installed.

You can also test with tools outside from the OpenERP runtime (via RPC) so
you can test different installation scenario. Tools like OERPScenario or
Rspec/Cucumber if you use Ooor can do these kind of tricks.


So you see, doing sustainable Odoo customization is sadly nearly an art of
its own. But I believe it makes all the difference between projects that
will work and others that will die.


All right, back to the game ;-)


-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 3942-2434
www.akretion.com




On Fri, Jul 4, 2014 at 4:58 PM, Denis Karataev <dskarataev@xxxxxxxxx> wrote:

> Hello Raphael,
>
> Thank you for your warning, maybe you're right. But I can explain why we
> decided to merge modules. Before we preferred to make 1 change = 1 module.
> And now we have many modules that inherit same parts of code in original
> modules. Also as all these modules aren't depend on each other, on
> different installations they have different sequence of installation time.
> Because all they depend only on original module, the system doesn't know
> what to install first, what to install second, etc. So now we have many
> "patches" for same code. Yes, inheritance mechanism works good and all this
> code works right, but we have 2 problems:
>
> 1. it became difficult to track all these small changes between modules.
> Often we don't remember all places of these changes when we're wrining
> module for new change of same original code. So developer have to find it
> all first and after that to think how to write new change in best way
>
> 2. more important: now we write tests for every module, and test result OK
> or FAIL depends on order of installing modules. For example if module A
> will be installed first, tests for module A will pass OK, but if module B
> will be installed first and then module A, in this case module A inherits
> already not original module but inheritance looks like this
> "original->module B->module A". But module A doesn't know about changes in
> module B. So we have FAIL result of tests in this case.
>
> Maybe you could recommend how to win in this situation? Thank you!
>
>
> 2014-07-05 2:43 GMT+07:00 Raphael Valyi <rvalyi@xxxxxxxxx>:
>
> Hello Denis,
>>
>> before all, I strongly recommend against merging several modules into a
>> single module!
>>
>> Why do I think this is extremely bad:
>>
>> By merging modules you'll destroy the information about the
>> responsibilities of each part of the customization.
>> That is you will create a nightmare for future migration.
>>
>> Indeed, when customizations are modular instead, when you migrate to a
>> new version, it will be way easier to migrate the code of modules one by
>> one according to the dependency order.
>> You also give you a better chance that as the years are passing, may be
>> some OCA or other quality module would fulfill some of your customization
>> requirements so that you can keep the volume of customization under control
>> and swap some custom module by some community maintained module.
>>
>> You know, in several years, the worst case of OpenERP installations I
>> have ever seen were all these installation with a single module of 5000
>> lines or more. Everytime I have been confronted to such situation it ended
>> with a "sorry, we won't be able to rescue your project, see with somebody
>> else" and most of the time the fool guy ended up abandoning OpenERP because
>> no fireman would ever take the risk to maintain a monolithic codebase.
>>
>> Now if you should really move modules around, well you should be ready
>> for SQL fighting. The tools of Openupgrade can also help you. But make no
>> mistake this is all quite involved.
>>
>> The fact that unstalling a module kills the module datastructure is
>> something that has been introduced in v7. Eventually you can hack in the
>> code to avoid that as it was in previous versions. I'm not convinced this
>> change was an improvement.
>>
>> Good luck though.
>>
>> --
>> Raphaël Valyi
>>  Founder and consultant
>> http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
>> +55 21 3942-2434
>> www.akretion.com
>>
>>
>>
>>
>> On Fri, Jul 4, 2014 at 4:29 PM, Denis Karataev <dskarataev@xxxxxxxxx>
>> wrote:
>>
>>> Hello community!
>>>
>>> We'd like to merge all modules that we developed inside same project to
>>> one module. So we should have 1 module = 1 project. Now it's about 25
>>> modules and we'd like to move code from all them to one folder, one module.
>>>
>>> But I don't understand how to do it? When I uninstall old modules it
>>> removes data from database. But how can I install new module without
>>> uninstalling old? It duplicates old modules.
>>>
>>> What is your recommendation?
>>>
>>> Thanks!
>>>
>>> --
>>> Denis Karataev.
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openerp-community
>>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openerp-community
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
>
> --
> Denis Karataev.
>