openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

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 <xrg@xxxxxxxxx> 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     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>