[MERGE] orm: cleand get_pg_type(). Changes as written in the merge prop.:
authorVo Minh Thu <vmt@openerp.com>
Thu, 6 Oct 2011 08:13:36 +0000 (10:13 +0200)
committerVo Minh Thu <vmt@openerp.com>
Thu, 6 Oct 2011 08:13:36 +0000 (10:13 +0200)
commit4dc26443d162a141adcf28d128475278d592ec3c
treef4c4aea7ef2a814f116b50a0df5e328977ab8888
parentc73c70550f1aa461dd95e85339f332ae66351475
parentcab4e9c4a51bf82ecc760a0219c2c0ff176da7d0
[MERGE] orm: cleand get_pg_type(). Changes as written in the merge prop.:
* 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
openerp/osv/orm.py