Hello, I remember I discussed that topic with Fabien a few months ago: Fabien insisted that the merging logic is always different and I certainly agree with that. However, I strongly support the idea of at least a common interface (eg empty method definition at the ORM layer), it would basically be composed of two abstract parts: 1) check if the merge is allowed 2) do the merge May be would could have some generic code here, but most of implementations would indeed override it to extend it.
Even if no implementation is actually shared I see a lot of value in factoring that "topological" merge abstraction into a common and explicit interface. Benefit would be: - less code chaos/more readable code - unified processing of merges, possibly even at the client side (GUI, error reports etc...). Indeed, currently you have dedicated "copy" button/methods. For me merge is just the same class of toplogical operation upon records and I think it deserves the same abstractions. So I personally totally weight behind that idea. Generally speaking, I see lot of amateurism with some dynamic languages users that never think about contract based programming under the pretext their language doesn't force them to do so as would statical languages (like virtual C++ methods, Java interfaces etc...). I think this is wrong, we need to factor abstractions even if implementation are not shared, this is very important to make openobject something generic an powerful and avoid that everyone introduce their own method signatures and chaos where would could actually have order. And also think that once established, chaos takes way much more energy to fight that it would take to prevent it from occurring upfront. Thank you to bring back this topic on the table. Raphaël Valyi http://www.akretion.com On Mon, Apr 5, 2010 at 1:29 PM, P. Christeas <[email protected]> wrote: > Taking a second look at the "account_merge_invoice" I somehow realize now > that > there might be a generic need for merging of records in OpenERP. > That is, let ORM have a merge(cr, uid, src=[id1, id2,...], dest=id, ..) > [1,2] > function. > The tricky part is to update referencing records. Example, when 2 partners > are > merged, all purchase orders should be updated to point to the merged id. > However, this would be quite easy to standardize into the ORM API. > > Such a generic implementation should solve the problem of knowing which > modules need to be updated when a merge occurs (what if my custom module > also > references partners and I have to update my tables? ). ORM /does/ know all > the > table relations. > > Of course, the implementation should have hooks, in order to customize the > behaviour at such an update (like, compute totals again or re-position > information, warnings or anything). > > > What do you think? Has there ever been some thought on this subject, > before? > > If that's ok with everybody, I think I could start a draft implementation > of > the feature at ORM level and ask you again about your opinion. > > > > > > [1] perhaps name the function "records_merge" or something more unique, > because "merge" is used in some places already. > [2] also, some wizards that implement merging functionality could be ported > to > the API. > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-framework > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-framework > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
