openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Guys,

more on this,

1) Not sure I've been clear enough when I said how Rails was doing with it:
in Rails, mainly because it has been design to work with MySQL who has no or
bad ACID features (Rails was mainly aimed at web site, not ERP's), Ruby
models are designed to check the data integrity BEFORE passing it to the
SGBD. If you pass such a wrong query in the SGBD in Rails, you get a similar
error from the SGBD and no further explanation. So eventually we could
achieve the same using the meta info embedded in the model fields
declaration,n may be a bit like the Python constraints are used today in
OpenERP.

This however is likely to generate overhead, for some check that would
already happen in the SGBD, so I'm not sure that's the right approach
indeed.

The other solution I was evocating was trying to parse/interpret the
Postgres error, using the object and his fields definition. Glad to see we
thought about the same thing.


2) I got a tweet from Cedric Krier ( http://twitter.com/cedrickrier ),
Tryton fork lead, and again, they claim they fixed that issue since Tryton
1.2:
"one more #openerp issue http://bit.ly/628cmy fixed in #tryton with generic
error messages since 1.2"

Probably worth an investigation.

Again, ripping code from other projects with a compatible license such as
Tryton would be perfectly all right (hey they largely did it) if Tiny had a
more professional approach to licensing. Currently, as Sharron mentioned in
an other thread, for whatever reason, they just try to hold all copyrights
no matter what merge they do.
I'm not sure that's the right approach, but firstly copying code from third
party means you should respect the third party copyright. Secondly, as for
third party friendly merges, I'm sure we are all very tolerant, but a mature
approach from Tiny would be to have a copyright agreement, just like say Sun
or Mozilla for instance where contributors accept to give officially
copyright ownership to Tiny. There isn't such a thing currently (I think I
highlighted this issue like 1,5 year ago) and this weaken Tiny a lot legally
speaking. If they were to go that way (might avoid issues with too many
copyright holders able to block the future decisions), a good practice would
however certainly be to mention the code authors, even if they gracefully
gave the copyright ownership. All right, is for an other thread to be
discussed, but I just wanted to make that remark here when we speak about
taking code from elsewhere.


Raphaël Valyi
http://www.akretion.com


2010/1/25 Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>

> +1 => That's a great idea and a good news !!
>
> Good luck and thanks for the investigating !
>
> Regards,
>
>
>
> Le 25 janv. 2010 à 09:24, Davide Corio a écrit :
>
> Il giorno dom, 24/01/2010 alle 18.38 -0200, Raphaël Valyi ha scritto:
>
> Hello,
>
>
>
> I also recommend issuing more user friendly messages, but only if that
>
> could be done in a generic manner. I would be sad if the solution was
>
> to dilute non-consitent/unmaintainable exception messages all over the
>
> place in every possible case.
>
>
> Hi Raphaël,
>
> yes, i perfectly understand your point of view.
> We are here to improve and "clean" openobject, so every new features
> must be smartly coded.
>
> While trying to interpret the error, may be the stack and/or the
>
> ir_model and/or ir_model_fields table could be used to help build a
>
> user friendly message.
>
>
> this is exactly what i have in mind
>
> But notice that, in Rails you would generate such model data integrity
>
> controls with human messages at the model layer for that. It's much
>
> like the field declaration in the objects will generate specific
>
> validations at the model layer when trying CRUD operations, may be
>
> it's the way to go (strangely I was dealing with that yesterday in
>
> Rails).
>
>
> Similar to what happens with other frameworks, so it should be the right
> approach.
>
> But i'm not sure openobject already provides all of what we need to
> proceed that way.
>
> i'll investigate
> --
> Davide Corio
> email: davide.corio<at>domsense.com
> web: http://www.domsense.com
>
>
> _______________________________________________
> 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
>
>
> --
>
>
> *Joël Grand-Guillaume** *
> *OpenERP Consultant*
> *Business Solutions*
> *
> *
> *Camptocamp SA*
> PSE A, CH-1015 Lausanne
>
>  www.camptocamp.com
>
>
> Phone: +41 21 619 10 28
> Office: +41 21 619 10 10
> Fax: +41 21 619 10 00
> Email: joel.grandguillaume@xxxxxxxxxxxxxx
> http://www.camptocamp.com/fr/business-solutions/formations
>
>
> _______________________________________________
> 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
>
>