openerp-community team mailing list archive

[Denis Karataev <dskarataev@xxxxxxxxx>]

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


2014-07-05 6:56 GMT+07:00 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
>>
>>
>


-- 
Denis Karataev.