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 <[email protected]> > +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 : [email protected] > 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: [email protected] > http://www.camptocamp.com/fr/business-solutions/formations > > > _______________________________________________ > 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
