openerp-community team mailing list archive

[Sebastien Beau <sebastien.beau@xxxxxxxxxxxx>]

@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 <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.
>>
>
>
> _______________________________________________
> 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
>
>