openerp-expert-framework team mailing list archive

[Gustavo Adrian Marino <gamarino@xxxxxxxxx>]

Let me share my understanding on the new API

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.
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.
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).
This raise some interesting questions:

   1. The GUI still have the need to cache all affected values,
   2. 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?
   3. Once the whole thing is maintened on server, is it not possible to
   provide a mobile read and update interface with a reasonable effort?
   4. 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"
   5. 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

I hope I am not guessing too much!

Best regards



El 17 de abril de 2012 08:46, Olivier Dony <odo@xxxxxxxxxxx> 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     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>



-- 

Gustavo Adrian Marino

Mobile: +54 911 5498 2515

Email: gamarino@xxxxxxxxx

Skype: gustavo.adrian.marino