On Mon, Apr 23, 2012 at 11:02 PM, Gustavo Adrian Marino <[email protected]> wrote: > Let me share my understanding on the new API
Seems good to me, excpet a key point. > Even it is not explicit in the description, it seems that the new API is > holding on the server the temporary state of the records during an edit > session, something it use to be done on the GUI til v6.1. If I am not wrong > that means the approach will hold the state of the tree of accessed and > modified objects, which is the only way to provide the required parameters > to the new on change methods. Yes, but not as much as you describe below. > The approach is intelligent, provided it is not adding artificial roud trips > to the GUI. What I mean is that on fields_view_get, it should be computed if > the control should be passed back to the server when a GUI field is changed > (taking into account if any other field is depending on the value of the > field). Once the GUI detect that condition, it should ask the server for the > new field values. > In order to construct an answer, the server should call all affected fields > (recursivelly if it is necesary, taking into account loops), and send back > to the GUI all changed values. Yes. > If I am not guessing too much, that means the session status is going to be > cached on server as long the user is editing an object (and all related and > the corresponding relations). No. There is no need to keep an edited record on the server. The client can send everything: unmodified and modified fields. Right now the client sends only the parameters excplicitely mentioned in the on_change. Instead in the future it will send everything. The payload is thus increased but the number of round-trip is reduced as all cascading on_changes will be applied at once. > This raise some interesting questions: > > The GUI still have the need to cache all affected values, > I see an opportunity to fully implement a transaction like behaviour. Today > when you click on a button, all the temporary state is dumped to DB. This > causes a difficult situation for the user because he has not press the save > button and the info is already on DB!. It is completely counterintuitive. > With the new strategy it is possible to fully delay the DB update operation > till the user has explicitely press the save button. Is that feature > foreseen? No. We don't want to have a transactional behavior across the network. > Once the whole thing is maintened on server, is it not possible to provide a > mobile read and update interface with a reasonable effort? > Be carefull not to be tempted to go back in the road a full stateless > server. Please do not relay on server process to server process > communication to resynch the temporary state (as some messages in the expert > threads suggest). Today for medium to big implementations a redundant on > line server is a requirement for big customers. Please use any strategy to > keep the servers independent from each other (synch through database or > whatever), but do not give up on the target to achieve full "statelessness" > It seems a good opportunity to fully get rid of the limitation on read only > fields, that could not be updated programmatically or on default_get, and at > the same time prevent the user to modify them We still want to keep the server as stateless as possible. Cheers, Thu > I hope I am not guessing too much! > > Best regards > > > > El 17 de abril de 2012 08:46, Olivier Dony <[email protected]> escribió: > >> On 04/16/2012 02:13 PM, Alexandre Fayolle wrote: >> > Hello Olivier >> > >> > Since you answered off-list, I'll do the same, but feel free to forward >> > my message to the mailing list if you feel it belongs there. >> >> My bad, my answer was meant for the list, sorry about that! >> Hope the quoted answer will be readable enough for anyone interested, >> otherwise >> I'll forward the original answer. >> >> >> > On lun. 16 avril 2012 13:03:59 CEST, Olivier Dony wrote: >> >> On 04/16/2012 11:26 AM, Alexandre Fayolle wrote: >> >>> Another point which should be clarified if the record_set.method(args) >> >>> is implemented is the behaviour wrt exceptions. The behaviour of >> >>> method(args) raising an exception for one of the ids of the recordset >> >>> should be well defined, which seems a bit awkward : >> >> >> >> It must be very clear for the developer indeed, but there is perhaps >> >> not much >> >> to invent here, the semantics are already quite established I think. >> > >> > I'm sorry I'm such a newbie openerp-wise. The slides made absolutely no >> > mention of exception handling, and this is one of the points which >> > deserve a note in the API specification, imo. I'll study more the >> > existing behaviour. Also if the explicit looping is still available, >> > then of course it is not necessary to add complexity to the vectorized >> > API. >> >> You're right, this is something that was overlooked in the slides because >> we >> did not foresee any major change in it, but it is definitely an important >> API >> concept to mention in the specs. >> >> >> >>> * the API must clearly state whether it will try to call the method on >> >>> remaining records after a call on a record has failed with an >> >>> exception >> >>> or not >> >> >> >> This has always been quite clear (I hope!): everything is happening >> >> within a >> >> transaction and the transaction is aborted and rolled back immediately >> >> as a >> >> whole. It is vital for an ERP framework to guarantee the proper >> >> fail-fast >> >> handling of transactions everywhere... even when developers wish it was >> >> working >> >> otherwise ;-) >> > >> > That's fine when the method is doing pure in-DB transactional stuff, >> > but can get awkward when the status is mixed (such as with method both >> > affecting DB state and the outside world) >> >> Certainly, when you're mixing transactions with non-transactional things >> (e.g. >> emails) you need to decide how you want to maintain transactional >> consistency >> and data integrity. This is probably more of a case-by-case choice, >> though. >> Common approaches could be to postpone the external calls to the last step >> of >> the transaction (when the rest is validated and ready to commit), or wrap >> it in >> a transactional layer (like our email queue), etc. >> >> >> >> Practically speaking, if your business code needs to call a method on a >> >> record_set, it should either: >> >> - call it on the whole record_set and let any error propagate upstream >> >> untouched - presumably something unexpected happened and the original >> >> caller >> >> needs to be notified >> >> - or switch to a `for` + `try/except` approach in order to handle >> >> *expected* >> >> downstream errors record-per-record (being careful to let *unexpected* >> >> errors >> >> propagate) >> >> >> >> In both cases the semantics seem simple, clear and consistent, don't >> >> they? >> > >> > Once the exception handling strategy is clearly worded, yes :-) >> > >> > -- >> > Alexandre Fayolle >> > Chef de Projet >> > Tel : + 33 (0)4 79 26 57 92 >> > >> > Camptocamp France SAS >> > Savoie Technolac, BP 352 >> > 73377 Le Bourget du Lac Cedex >> > http://www.camptocamp.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 > > > > > -- > > Gustavo Adrian Marino > > Mobile: +54 911 5498 2515 > > Email: [email protected] > > Skype: gustavo.adrian.marino > > > > > > > > _______________________________________________ > 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
