(Otherwise changes happening on one cursor are not visible to the other one.)
Normally, as those yaml files commit(), they sould be inside demo data
instead of tests. But really we want to test a completely initialized
database, not being executed while the database is being initialized
(as the demo data are). This is just a matter of convention as the
tests are only executed when you also install demo data.
bzr revid: vmt@openerp.com-20111007091737-2dzocv2rgm2gfbi2
* Extracted creation of VARCHAR pg_type into a separate function, make missing
size (or size 0) create an unlimited VARCHAR field (effectively limited by
postgres to 1GB data)
* Extracted fields to pg_types mapping outside of get_pg_type
* Made fields.function recursively forward to get_pg_type (via a type overload)
instead of reimplementing half get_pg_type in itself
* Simplified some get_pg_type cases
Note: if this is merged, it might be nice to convert fields.selection to use an
API similar to fields.function: default to VARCHAR storage, if there's a type
attribute override use that type. Currently, fields.selection is handled the
following way:
* If the selection is a list and the type of the first half of the first item
is an integer, use type int4
* If the field has a __size=-1__ attribute, use type int4
* Else use type varchar (with size specified on the field, if any)
One change from previous version is that if type of the first half of the first
item of the selection was str or unicode, it tried to find the longest string
and used that as the field's size. This meant silent loss of data if new,
longer items were added to the selection without recreating the whole db (or at
least manually altering the relevant fields). It also used the field's size or
*16* as a minimum default, for some reason, and if there was no size specified
on the selection (or size=0) it just hardcoded the size to 16.
bzr revid: vmt@openerp.com-20111006081336-uka6srvdmvs0s4lm
Plan was originally to just ignore this because "it should just work"
but turns out m2o and m2o[@widget=selection] fields have very
different behaviors when it comes to default values, especially
custom domains and contexts:
* An m2o field uses its string value always (behaves like a char
field), for UI and clarity purposes we added an [[name, '=', id]]
case when the user specifically selects an autocompletion value,
but that's not "cannon", when it comes to dealing with custom
domains (filter_domain) and contexts the field always uses its
string value.
* An m2o[@widget=selection] field on the other hand uses its ids
always (behaves like a selection field).
That's not entirely true, really, because it has the converse to
what we implemented on the m2o field in the web client (in the GTK
client): if there is no @filter_domain *and* the user has entered a
value which is not in the dropdown (it's a combobox in the GTK
client), then it falls back on using 'ilike'. This string value is
*not* used in custom domains and custom filters, which simply are
not submitted.
This second section has *not* been implemented so far in the web
client, we'll come round to it if people actually need it.
bzr revid: xmo@openerp.com-20111006063949-fl5rbg3wwubcaay8
Vo Minh Thu
Quentin (OpenERP)
Olivier Dony
Xavier Morel
Launchpad Translations on behalf of openerp
Antony Lesuisse
Stephane Wirtel
Fabien Meghazi