Thank you guys! Your recommendations are very helpful for me!
2014-07-05 6:56 GMT+07:00 Sebastien Beau <[email protected]>: > @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 <[email protected]>: > > 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 <[email protected]> >> 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 <[email protected]>: >>> >>> 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 <[email protected]> >>>> 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 : [email protected] >>>>> Unsubscribe : https://launchpad.net/~openerp-community >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>> >>> >>> -- >>> Denis Karataev. >>> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openerp-community >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-community >> More help : https://help.launchpad.net/ListHelp >> >> > -- Denis Karataev.
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
