openerp-expert-framework team mailing list archive

[Vo Minh Thu <vmt@xxxxxxxxxxx>]

On Mon, Apr 23, 2012 at 11:02 PM, Gustavo Adrian Marino
<gamarino@xxxxxxxxx> 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 <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
>
>
>
>
>
>
>
> _______________________________________________
> 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
>