* 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
Python has an iteration fallback protocol: when iterating over an
object which does not define __iter__, if the object defines
__getitem__ it considers that it's a list, and invokes __getitem__
from index `0`.
This can be a problem in openerp in methods which expect an list of
ids but are only given a single id (not a singleton list), in that
case self.browse() will return a single browse_record (instea of a
list) and the method tries to iterate over it by calling
browse_record.__getitem__.
Problem is that browse_record.__getitem__ is pretty deep and does
little validation, so the error appears 3 frames below where the
actual issue is with a completely cryptic message of "KeyError: 0",
which makes the actual harder to track.
By raising an error immediately in browse_record.__iter__, this kind
of issues is much easier to handle, the stack points precisely to the
frame in error with a clearer message.
bzr revid: xmo@openerp.com-20111005112444-jcp9fw6pa36ahpsd
- _original_module is now available on model/browse_records
- context usage in res.partner.*
- proper name_search() + default values for res.currency
- active_model in wkf exec context
- safe_eval allows try/except/finally
- yaml_import: !ref {id: xml_id} works
- ir_mail_server: support for alternative body/subtype
- default value for web.base.url config parameter
- consistency rename: Model.*get_xml_id* -> *get_external_id*
bzr revid: odo@openerp.com-20111005100954-c8mbd4kz6kkqaj84
The 'module' field of ir.model.data is required, so we
we need to set it when auto-generating ir.mode.data
entries. This acts as the namespace of the record.
Because we don't want exported records to look like they
belong to an existing module (and risk being garbage
collected at the next module update), we put these
auto-generated names in a reserved '__export__' module
namespace.
bzr revid: odo@openerp.com-20111004205140-duaww77ng4qmktj2
ORM Models already have a _module attribute that contains the
name of the module that declared this class, however
sometimes we also need the name of the module that
declared this model the first time.
This will be stored in _original_module and is the
name of the module to which the first parent with
the same _name belongs to.
bzr revid: odo@openerp.com-20111004204705-8z9o70n1ynpvng3i
fields_view_get removed multi=True actions from the result of
ir_values.get_actions('client_action_multi', ...), so that multi
actions would not be displayed in the form view's sidebar in the GTK
client.
The web client has a sidebar in both cases, the GTK client just
ignores 'toolbar' key if not in tree view, so don't remove 'multi'
actions in tree view toolbar, to avoid having to perform one more RPC
call (explicit ir_values.get) in web client.
lp bug: https://launchpad.net/bugs/856378 fixed
bzr revid: xmo@openerp.com-20110929130701-65ubx1o0swk889nl
This allows for transparent inheritance of m2m columns via _inherit,
as long as the m2m relationship table is not explicitly named in
the declaration.
bzr revid: odo@openerp.com-20110926171451-n2jg8pbl5mq715vk
We'll now have a BaseModel with 3 subclasses, AbstractModel,
TransientModel and Model. Model is for regular models,
TransientModel for automatically-vacuumed models, and
AbstractModel for common superclasses meant to be
inherited by other models only, and not directly used.
bzr revid: odo@openerp.com-20110923124525-jfzk55dk3ban2ps2
Quoting column names make the case-sensitive in PostgreSQL,
and this is the default strategy we are using so far. It is
important to be consistent there.
We might want to do the same to table names too.
This allows create fields with mixed cases names for example.
bzr revid: odo@openerp.com-20110919201845-heer0rttcouvtc9x
- Refactoring to make the function readable and maintainable
- Fixed algorithm to properly take into account the priority of all stored functions,
and not just the priority of the first function for a given model, which could hide
other stored function with higher priorities.
lp bug: https://launchpad.net/bugs/715470 fixed
bzr revid: odo@openerp.com-20110919091952-05lfl2kncr3ep9nj
* Search already used etree internally, remove serialization to string
* form and tree were easy to convert
* pull down fvg's parsing (etree.fromstring) into calendar generator before converting it
bzr revid: xmo@openerp.com-20110915120429-syz190w61iq52rel
The only requirements for this to work are:
- all model methods likely to be called on a browse_record must support
a context parameter (positional or keyword, doesn't matter)
- callers should never pass the context as a positional args, otherwise
we'll have multiple values for the context.
Both requirements seem sensible enough.
bzr revid: odo@openerp.com-20110913130826-d7fme3mznv55ok5f
* if the first element of the choices list is an integer, use int4
* if the field has a size, use that size
* else use an unrestricted varchar
bzr revid: xmo@openerp.com-20110909152307-ralzt1g8l1b3e46x
* add a type override to get_pg_type, so the function field can pass itself as another field type
* special-case the 'selection' role, not sure it's correct but it was pretty special last time around (I guess since we don't have the field's values available we can't just do the type/size inference of get_pg_type)
bzr revid: xmo@openerp.com-20110909145213-y172z8eyfnond43w
do replacement in two passes of re-base replacement: replace old-style 'field:id' and 'field.id' in resp. 'field/id' and 'field/.id', don't touch anything else (especially not 'field/.id') and leave them through instead.
bzr revid: xmo@openerp.com-20110831094547-8evd7ecm5qojspnr
The option is not completely flexible (no possibility to choose to have a foreign
key on one of the fields. No similar option is provided for many2one either.
It is seldom used (e.g. in account_followup addons).
bzr revid: vmt@openerp.com-20110829094354-0yf6t6329j8e765q
This is necessary to preserve the model loading order
as defined in the module. This was broken when the
metaclass was introduced to make the explicit model
constructor call optional.
One consequence is that the order in which the classes
are declared in the module really defines their
initialization order, even if the constructors are
later called explcitly in a different order.
This latter case should be fairly rare, and easy to
fix too - simply putting the class declaration in the
right order.
bzr revid: odo@openerp.com-20110826161736-lgnpurtbcqtbseey
The problem is that when you have a field in an object, and that field
is also defined in its parent (defined with _inherits), when OpenERP creates
the object, the field value was used to fill the parent value, not object.
bzr revid: t.dirlik@adep.com-20110825145856-2qa7im2awmm5gxjz