openerp-expert-framework team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

On 06/01/2012 09:01 AM, Thibaut DIRLIK wrote:
> In 6.0 and GTK, I used to have things like this in my views :
> 
> <field name="my_one2many_ids" context="{'existing_one2meny_entries' :
> my_one2many_ids}"/>
> 
> This is useful if you want to define some defaults for a new element which
> depends on existings one.
> However, with the new web client, this context can't eval properly, I got a
> "my_one2many_field_ids is not defined".

It's explicitly prevented in the 6.1 web client, to avoid a gray area of
unreliable behavior. One2many fields cannot always be serialized reliably
inside themselves, so it is prevented and you can only refer to their values
from outside, IIRC.

Relying on this "hack" was perhaps not a good idea in GTK either, as the result
may be surprising in many situations - it was certainly never specified nor
documented as a feature.
Let's say the o2m initially contained 2 values: [32,34], what do you think will
be the "evaluated value" in context after you have deleted ID 32, added one new
line, and are now modifying the ID 34 one?
- [32,34]
- [(0,0,{...}),(2,32),(4,34)] (w/o the current edit)
- [(0,0,{...}),(2,32),(1,34,{...})]  (with a partial form of current edit)
- [(0,0,{..}),(1,34,{..})] (w/o the deletion, as it's technically not a value)
Is your code prepared to deal with all these cases?


Now it's perhaps a good opportunity to come up with a more formal spec for the
future, if there is any interest...

How do you guys think o2m serialization should work in the various cases?

0) When returned by read() (server-side)
1) When returned as a _defaults value for a o2m field? (addons side)
2) When sent to create()? (client side)
3) When sent to write()? (client side)
4) When evaluated (client-side), e.g for on_change parameters or attrs?
5) Any other cases?


As a starting point:

0) read() will always return real values with IDs, so keeping the current
format [ID1,ID2,...] sounds like the KISS option, with `False` indicating no value.
In fact if we decided that the LINK(4) command is the default o2m command,
[32,34] could simple be a simplified version of [(4,32),(4,34)], so we'd be
using consistent formats in the various contexts.

1) default_get() result is supposed to be similar to read(), so you'd be
tempted to say: exactly the same as for 0). Except you also need to return
default values that don't exist yet, and have no ID -> need to mix existing
values with new ones. As a result, we could say:
-> must always be a list of o2m commands LINK(4) or CREATE(0), and if LINK(4)
is the default, read()-like results would be supported too.
Should the RESET-LINK(6) command be accepted here too?

2) create() should only ever LINK(4) or CREATE(0) values, but other commands
are supported now, which I suppose is fine. If LINK(4) is the default, we'd
have to support bare IDs too in the command list.

3) write() is meant to support the full range of commands (1-6), and should be
adapted to support bare IDs too if LINK(4) becomes a default.
Now, should the order of the commands matter? There are cases where it does,
become the ORM will respect the order when performing the operations, so a
CREATE(0) fail with a unique constraint violation simply because the DELETE(2)
that follows should have been executed before. Or perhaps the ORM should always
reorder the operations before performing them: [2,3,5,0,1,4,6]?

4) For consistency we could say that the format for this case is the same as
the one for 1), as the intent is the same:"What are the current lines,
including possibly unsaved ones?"
This means deletions will not be returned, so if you need to know what was
deleted you'll have to diff against the current saved value.
What about partial changes and evaluating the o2m value while you're modifying
it (i.e. inside it)? If you are editing a o2m child record but haven't finished
yet, should the serialized value include some partial changes? Obviously it
cannot work 100%, so perhaps it should only include changes up to the last time
you started editing a line... but we can't really tell that, can we? (think
editable lists etc.)

5) ?


As you see, this is not a trivial topic ;-)