- allow leading spaces in orderby spec for m2o columns
- extra test for read_group on multiple columns
- proper handling of groupby on numeric column with default order
bzr revid: odo@openerp.com-20140304152927-havybom9x1jgdzae
Fixed the implementation of the sorting for inherited
columns, many2one columns, and aggregated columns.
Added corresponding tests with increased coverage of
the read_group() method.
bzr revid: odo@openerp.com-20140228173320-p8l0jc8op7xsgn1x
When a varchar column has a dependence on a view, we cannot change the size in-place,
we need to manually re-create the column with the correct type.
bzr revid: chs@openerp.com-20140217182045-qor70r3gb0fch2ki
Sorting was done using a search on ids that where found in a custom SQL field,
only 1 record among aggregated records with same groupby value was used
when using search for ordering, resulting data ordered on
max(aggregated_data).field_value instead of sum(aggregated_data.field_value).
lp bug: https://launchpad.net/bugs/1060086 fixed
bzr revid: acl@openerp.com-20140217172926-ka2fw8t2l3cqi7h3
Historically, we used a copy+rename technique during
table upgrades to alter varchar columns sizes.
This was only necessary to permit downsizing
columns, which we do not want to do anymore (it is
too dangerous, so has to be done explicitly when
required).
Switching to a pure ALTER COLUMN TYPE is simpler
and also much faster for large tables.
Also fixed the inappropriate name used for
temporary columns during column type casting
(which *does* require the copy+rename technique).
bzr revid: odo@openerp.com-20140217164239-0iou3dsiea3foabb
- removing the need of the use of search when groupby is set on a relation
field.
- creation and use of dedicated helper method to compute the orderby clause
for easier reading
bzr revid: acl@openerp.com-20140217140144-2rm3o00g76tyhqxn
Sorting was done using a search on ids that where found in a custom SQL field,
only 1 record among aggregated records with same groupby value was used
when using search for ordering, resulting data ordered on
max(aggregated_data).field_value instead of sum(aggregated_data.field_value).
lp bug: https://launchpad.net/bugs/106086 fixed
bzr revid: acl@openerp.com-20140203125854-ypi0bu0lbhatg9b1
Issue introduced in
revid:chm@openerp.com-20130828161130-641xsmbr8xm53xjx: context of a
fields_view_get can provide a *_view_ref name (e.g. tree_view_ref),
whose value is an xid for the view to use (can be used to specify a
view instead of providing a view_id, mostly for embedded views where
there is no way to provide a view_id).
The view_ref being an external id, it must be dotted. Historically,
undotted xids were silently ignored and the system just skipped to
getting the default view for the model (lowest priority view where
inherit_id is null).
In revid:odo@openerp.com-20130821122955-8c9z0mi8cu48rne3 this behavior
was altered to emit a warning when ignoring a malformed view_ref. When
this change was merged into trunk-website-al, the conditional
(view_ref and '.' in view_ref) was split without consideration for the
semantics change: a syntactically invalid view_ref would fall off the
first branch (view_ref) instead of taking the second one (not
view_ref), the code would not fetch the default view for the model and
would instead generate one (through _get_default_%(viewtype)s_view).
However, closer reading reveals the code was already broken in a
specific case of a syntactically valid but unknown xid (view_id
wouldn't get assigned in the first branch, but the code would not take
the second one, resulting yet again in a view generation even if the
database contains a valid view for the model and type).
Fixed by reintroducing explicit second check on view_id, instead of
merely conditional alternative.
bzr revid: xmo@openerp.com-20140123075742-603n2zthqhxee07y