[Openerp-community] Merge several modules to one

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[Openerp-community] Merge several modules to one

Denis Karataev
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Merge several modules to one

Raphael Valyi
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
+55 21 3942-2434




On Fri, Jul 4, 2014 at 4:29 PM, Denis Karataev <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Merge several modules to one

eLBatti
In reply to this post by Denis Karataev

> What is your recommendation?
>

To avoid to merge :-)


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Merge several modules to one

Denis Karataev
In reply to this post by Raphael Valyi
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 <[hidden email]>:
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
+55 21 3942-2434




On Fri, Jul 4, 2014 at 4:29 PM, Denis Karataev <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





--
Denis Karataev.

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Merge several modules to one

Ana Juaristi
In reply to this post by eLBatti

+1Raphael and Lorenzo but...
If modules are too small changing so little concept and you are inheriting several times as you said, then merging them wouldn't be a bad idea.
So i recomend before doing anything you think about functional blocks covering specific funtionality. Each one of this blocks would be a sustainaible module.
Question is not having one single or 25 modules but clearly defining functionality covered by each of them.
As much small and clear it is, it will be better.
My 2cents

El 04/07/2014 22:09, "Lorenzo Battistini" <[hidden email]> escribió:

> What is your recommendation?
>

To avoid to merge :-)


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Merge several modules to one

Raphael Valyi
In reply to this post by Denis Karataev
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
+55 21 3942-2434




On Fri, Jul 4, 2014 at 4:58 PM, Denis Karataev <[hidden email]> 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 <[hidden email]>:

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
<a href="tel:%2B55%2021%203942-2434" value="+552139422434" target="_blank">+55 21 3942-2434




On Fri, Jul 4, 2014 at 4:29 PM, Denis Karataev <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





--
Denis Karataev.


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Merge several modules to one

sebastien beau
@Denis
Regarding the migration process the best is 

0: comment code that drop the data
1: get a copy of prod database
2: uninstall the big module
3: do some sql request
4: install the new modules
5: do some sql request
6: until it's not perfect go back to step 1

You can take a look to this path for commenting code

=== modified file 'openerp/addons/base/ir/ir_model.py'
--- openerp/addons/base/ir/ir_model.py  2014-05-15 14:25:51 +0000
+++ openerp/addons/base/ir/ir_model.py  2014-06-24 07:00:56 +0000
@@ -164,7 +164,7 @@
                 if model.state != 'manual':
                     raise except_orm(_('Error'), _("Model '%s' contains module data and cannot be removed!") % (model.name,))
 
-        self._drop_table(cr, user, ids, context)
+        #self._drop_table(cr, user, ids, context)
         res = super(ir_model, self).unlink(cr, user, ids, context)
         if not context.get(MODULE_UNINSTALL_FLAG):
             # only reload pool for normal unlink. For module uninstall the
@@ -323,7 +323,7 @@
                 any(field.state != 'manual' for field in self.browse(cr, user, ids, context)):
             raise except_orm(_('Error'), _("This column contains module data and cannot be removed!"))
 
-        self._drop_column(cr, user, ids, context)
+        #self._drop_column(cr, user, ids, context)
         res = super(ir_model_fields, self).unlink(cr, user, ids, context)
         if not context.get(MODULE_UNINSTALL_FLAG):
             cr.commit()

=== modified file 'openerp/addons/base/module/module.py'
--- openerp/addons/base/module/module.py        2014-04-10 09:58:17 +0000
+++ openerp/addons/base/module/module.py        2014-06-24 07:00:56 +0000
@@ -437,8 +437,8 @@
         ir_model_constraint = self.pool.get('ir.model.constraint')
         modules_to_remove = [m.name for m in self.browse(cr, uid, ids, context)]
         modules_to_remove_ids = [m.id for m in self.browse(cr, uid, ids, context)]
-        constraint_ids = ir_model_constraint.search(cr, uid, [('module', 'in', modules_to_remove_ids)])
-        ir_model_constraint._module_data_uninstall(cr, uid, constraint_ids, context)
+#        constraint_ids = ir_model_constraint.search(cr, uid, [('module', 'in', modules_to_remove_ids)])
+#        ir_model_constraint._module_data_uninstall(cr, uid, constraint_ids, context)
         ir_model_data._module_data_uninstall(cr, uid, modules_to_remove, context)
         self.write(cr, uid, ids, {'state': 'uninstalled'})
         return True

Hope this will help you


2014-07-04 23:05 GMT+02:00 Raphael Valyi <[hidden email]>:
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
<a href="tel:%2B55%2021%203942-2434" value="+552139422434" target="_blank">+55 21 3942-2434




On Fri, Jul 4, 2014 at 4:58 PM, Denis Karataev <[hidden email]> 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 <[hidden email]>:

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
<a href="tel:%2B55%2021%203942-2434" value="+552139422434" target="_blank">+55 21 3942-2434




On Fri, Jul 4, 2014 at 4:29 PM, Denis Karataev <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





--
Denis Karataev.


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Merge several modules to one

Denis Karataev
Thank you guys! Your recommendations are very helpful for me!


2014-07-05 6:56 GMT+07:00 Sebastien Beau <[hidden email]>:
@Denis
Regarding the migration process the best is 

0: comment code that drop the data
1: get a copy of prod database
2: uninstall the big module
3: do some sql request
4: install the new modules
5: do some sql request
6: until it's not perfect go back to step 1

You can take a look to this path for commenting code

=== modified file 'openerp/addons/base/ir/ir_model.py'
--- openerp/addons/base/ir/ir_model.py  2014-05-15 14:25:51 +0000
+++ openerp/addons/base/ir/ir_model.py  2014-06-24 07:00:56 +0000
@@ -164,7 +164,7 @@
                 if model.state != 'manual':
                     raise except_orm(_('Error'), _("Model '%s' contains module data and cannot be removed!") % (model.name,))
 
-        self._drop_table(cr, user, ids, context)
+        #self._drop_table(cr, user, ids, context)
         res = super(ir_model, self).unlink(cr, user, ids, context)
         if not context.get(MODULE_UNINSTALL_FLAG):
             # only reload pool for normal unlink. For module uninstall the
@@ -323,7 +323,7 @@
                 any(field.state != 'manual' for field in self.browse(cr, user, ids, context)):
             raise except_orm(_('Error'), _("This column contains module data and cannot be removed!"))
 
-        self._drop_column(cr, user, ids, context)
+        #self._drop_column(cr, user, ids, context)
         res = super(ir_model_fields, self).unlink(cr, user, ids, context)
         if not context.get(MODULE_UNINSTALL_FLAG):
             cr.commit()

=== modified file 'openerp/addons/base/module/module.py'
--- openerp/addons/base/module/module.py        2014-04-10 09:58:17 +0000
+++ openerp/addons/base/module/module.py        2014-06-24 07:00:56 +0000
@@ -437,8 +437,8 @@
         ir_model_constraint = self.pool.get('ir.model.constraint')
         modules_to_remove = [m.name for m in self.browse(cr, uid, ids, context)]
         modules_to_remove_ids = [m.id for m in self.browse(cr, uid, ids, context)]
-        constraint_ids = ir_model_constraint.search(cr, uid, [('module', 'in', modules_to_remove_ids)])
-        ir_model_constraint._module_data_uninstall(cr, uid, constraint_ids, context)
+#        constraint_ids = ir_model_constraint.search(cr, uid, [('module', 'in', modules_to_remove_ids)])
+#        ir_model_constraint._module_data_uninstall(cr, uid, constraint_ids, context)
         ir_model_data._module_data_uninstall(cr, uid, modules_to_remove, context)
         self.write(cr, uid, ids, {'state': 'uninstalled'})
         return True

Hope this will help you


2014-07-04 23:05 GMT+02:00 Raphael Valyi <[hidden email]>:

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
<a href="tel:%2B55%2021%203942-2434" value="+552139422434" target="_blank">+55 21 3942-2434




On Fri, Jul 4, 2014 at 4:58 PM, Denis Karataev <[hidden email]> 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 <[hidden email]>:

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
<a href="tel:%2B55%2021%203942-2434" value="+552139422434" target="_blank">+55 21 3942-2434




On Fri, Jul 4, 2014 at 4:29 PM, Denis Karataev <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





--
Denis Karataev.


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





--
Denis Karataev.

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Merge several modules to one

Lionel Sausin
In reply to this post by Raphael Valyi
Le 04/07/2014 23:05, Raphael Valyi a écrit :
> 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>
I'd like to add that some changes are a lot easier/cleaner to maintain
as patches than modules.
Monkey-patches are pretty hard to maintain because you can't use version
control to help you.
Example:
- 12 lines patch, works fine
https://code.launchpad.net/~grupocitec/ocb-addons/report_webkit_custom_paper_size/+merge/195418
- same feature as a monkey patch module, 189 lines, was right at first
but now introduces regressions because the monkey-patch is outdated
https://code.launchpad.net/~bruno-bottacini/report-print-send/7.0-report_webkit_custom_paper_size/+merge/202892

Basically when the core is not modular or needs an obvious fix, on our
site we've decided to :
1/ patch the core to make it modular or fix it
2/ push our patch to a clean, mergeable, maintainable branch on
Launchpad/GitHub
3/ propose the branch for merging into the next core version (trunk/master)
4/ propose the branch for merging into the current OCB
Then by the time we migrate to the next version, hopefully the core is
fixed/modular and we can drop our patch.

Lionel

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp