""" Domain expression processing
-The main duty of this module is to compile a domain expression into a SQL
-query. A lot of things should be documented here, but as a first step in the
-right direction, some tests in test_osv_expression.yml might give you some
-additional information.
-
-For legacy reasons, a domain uses an inconsistent two-levels abstract syntax
-(domains are regular Python data structures). At the first level, a domain
-is an expression made of terms (sometimes called leaves) and (domain) operators
-used in prefix notation. The available operators at this level are '!', '&',
-and '|'. '!' is a unary 'not', '&' is a binary 'and', and '|' is a binary 'or'.
-For instance, here is a possible domain. (<term> stands for an arbitrary term,
-more on this later.)
+The main duty of this module is to compile a domain expression into a
+SQL query. A lot of things should be documented here, but as a first
+step in the right direction, some tests in test_osv_expression.yml
+might give you some additional information.
+
+For legacy reasons, a domain uses an inconsistent two-levels abstract
+syntax (domains are regular Python data structures). At the first
+level, a domain is an expression made of terms (sometimes called
+leaves) and (domain) operators used in prefix notation. The available
+operators at this level are '!', '&', and '|'. '!' is a unary 'not',
+'&' is a binary 'and', and '|' is a binary 'or'. For instance, here
+is a possible domain. (<term> stands for an arbitrary term, more on
+this later.)::
['&', '!', <term1>, '|', <term2>, <term3>]
-It is equivalent to this pseudo code using infix notation:
+It is equivalent to this pseudo code using infix notation::
(not <term1>) and (<term2> or <term3>)
-The second level of syntax deals with the term representation. A term is
-a triple of the form (left, operator, right). That is, a term uses an infix
-notation, and the available operators, and possible left and right operands
-differ with those of the previous level. Here is a possible term:
+The second level of syntax deals with the term representation. A term
+is a triple of the form (left, operator, right). That is, a term uses
+an infix notation, and the available operators, and possible left and
+right operands differ with those of the previous level. Here is a
+possible term::
('company_id.name', '=', 'OpenERP')
-The left and right operand don't have the same possible values. The left
-operand is field name (related to the model for which the domain applies).
-Actually, the field name can use the dot-notation to traverse relationships.
-The right operand is a Python value whose type should match the used operator
-and field type. In the above example, a string is used because the name field
-of a company has type string, and because we use the '=' operator. When
-appropriate, a 'in' operator can be used, and thus the right operand should be
-a list.
+The left and right operand don't have the same possible values. The
+left operand is field name (related to the model for which the domain
+applies). Actually, the field name can use the dot-notation to
+traverse relationships. The right operand is a Python value whose
+type should match the used operator and field type. In the above
+example, a string is used because the name field of a company has type
+string, and because we use the '=' operator. When appropriate, a 'in'
+operator can be used, and thus the right operand should be a list.
-Note: the non-uniform syntax could have been more uniform, but this would hide
-an important limitation of the domain syntax. Say that the term representation
-was ['=', 'company_id.name', 'OpenERP']. Used in a complete domain, this would
-look like:
+Note: the non-uniform syntax could have been more uniform, but this
+would hide an important limitation of the domain syntax. Say that the
+term representation was ['=', 'company_id.name', 'OpenERP']. Used in a
+complete domain, this would look like::
- ['!', ['=', 'company_id.name', 'OpenERP']]
+ ['!', ['=', 'company_id.name', 'OpenERP']]
-and you would be tempted to believe something like this would be possible:
+and you would be tempted to believe something like this would be
+possible::
- ['!', ['=', 'company_id.name', ['&', ..., ...]]]
+ ['!', ['=', 'company_id.name', ['&', ..., ...]]]
-That is, a domain could be a valid operand. But this is not the case. A domain
-is really limited to a two-level nature, and can not takes a recursive form: a
-domain is not a valid second-level operand.
+That is, a domain could be a valid operand. But this is not the
+case. A domain is really limited to a two-level nature, and can not
+take a recursive form: a domain is not a valid second-level operand.
Unaccent - Accent-insensitive search
-OpenERP will use the SQL function 'unaccent' when available for the 'ilike' and
-'not ilike' operators, and enabled in the configuration.
-Normally the 'unaccent' function is obtained from the PostgreSQL 'unaccent'
-contrib module[0].
+OpenERP will use the SQL function 'unaccent' when available for the
+'ilike' and 'not ilike' operators, and enabled in the configuration.
+Normally the 'unaccent' function is obtained from `the PostgreSQL
+'unaccent' contrib module
+<http://developer.postgresql.org/pgdocs/postgres/unaccent.html>`_.
+.. todo: The following explanation should be moved in some external
+ installation guide
-..todo: The following explanation should be moved in some external installation
- guide
+The steps to install the module might differ on specific PostgreSQL
+versions. We give here some instruction for PostgreSQL 9.x on a
+Ubuntu system.
-The steps to install the module might differ on specific PostgreSQL versions.
-We give here some instruction for PostgreSQL 9.x on a Ubuntu system.
+Ubuntu doesn't come yet with PostgreSQL 9.x, so an alternative package
+source is used. We use Martin Pitt's PPA available at
+`ppa:pitti/postgresql
+<https://launchpad.net/~pitti/+archive/postgresql>`_.
-Ubuntu doesn't come yet with PostgreSQL 9.x, so an alternative package source
-is used. We use Martin Pitt's PPA available at ppa:pitti/postgresql[1]. See
-[2] for instructions. Basically:
+.. code-block:: sh
> sudo add-apt-repository ppa:pitti/postgresql
> sudo apt-get update
-Once the package list is up-to-date, you have to install PostgreSQL 9.0 and
-its contrib modules.
+Once the package list is up-to-date, you have to install PostgreSQL
+9.0 and its contrib modules.
+
+.. code-block:: sh
> sudo apt-get install postgresql-9.0 postgresql-contrib-9.0
When you want to enable unaccent on some database:
+.. code-block:: sh
+
> psql9 <database> -f /usr/share/postgresql/9.0/contrib/unaccent.sql
-Here 'psql9' is an alias for the newly installed PostgreSQL 9.0 tool, together
-with the correct port if necessary (for instance if PostgreSQL 8.4 is running
-on 5432). (Other aliases can be used for createdb and dropdb.)
+Here :program:`psql9` is an alias for the newly installed PostgreSQL
+9.0 tool, together with the correct port if necessary (for instance if
+PostgreSQL 8.4 is running on 5432). (Other aliases can be used for
+createdb and dropdb.)
+
+.. code-block:: sh
> alias psql9='/usr/lib/postgresql/9.0/bin/psql -p 5433'
You can check unaccent is working:
+.. code-block:: sh
+
> psql9 <database> -c"select unaccent('hélène')"
Finally, to instruct OpenERP to really use the unaccent function, you have to
-start the server specifying the --unaccent flag.
-
-[0] http://developer.postgresql.org/pgdocs/postgres/unaccent.html
-[1] https://launchpad.net/~pitti/+archive/postgresql
-[2] https://launchpad.net/+help/soyuz/ppa-sources-list.html
+start the server specifying the ``--unaccent`` flag.
"""
import logging
+import traceback
from openerp.tools import flatten, reverse_enumerate
import fields
import openerp.modules
+from openerp.osv.orm import MAGIC_COLUMNS
#.apidoc title: Domain Expressions
TRUE_DOMAIN = [TRUE_LEAF]
FALSE_DOMAIN = [FALSE_LEAF]
-_logger = logging.getLogger('expression')
+_logger = logging.getLogger(__name__)
def normalize(domain):
"""Returns a normalized version of ``domain_expr``, where all implicit '&' operators
:param unit: the identity element of the domains "set" with regard to the operation
performed by ``operator``, i.e the domain component ``i`` which, when
- combined with any domain ``x`` via ``operator``, yields ``x``.
+ combined with any domain ``x`` via ``operator``, yields ``x``.
E.g. [(1,'=',1)] is the typical unit for AND_OPERATOR: adding it
to any domain component gives the same domain.
:param zero: the absorbing element of the domains "set" with regard to the operation
performed by ``operator``, i.e the domain component ``z`` which, when
- combined with any domain ``x`` via ``operator``, yields ``z``.
+ combined with any domain ``x`` via ``operator``, yields ``z``.
E.g. [(1,'=',1)] is the typical zero for OR_OPERATOR: as soon as
you see it in a domain component the resulting domain is the zero.
:param domains: a list of normalized domains.
""" Test whether an object is a valid domain term.
:param internal: allow or not the 'inselect' internal operator in the term.
- This normally should be always left to False.
+ This normally should be always left to False.
"""
INTERNAL_OPS = TERM_OPERATORS + ('inselect',)
return (isinstance(element, tuple) or isinstance(element, list)) \
# check if the expression is valid
if not is_leaf(e):
- raise ValueError('Bad domain expression: %r, %r is not a valid term.' % (exp, e))
+ raise ValueError("Invalid term %r in domain expression %r" % (e, exp))
# normalize the leaf's operator
e = normalize_leaf(*e)
left, operator, right = e
working_table = table # The table containing the field (the name provided in the left operand)
- fargs = left.split('.', 1)
+ field_path = left.split('.', 1)
# If the field is _inherits'd, search for the working_table,
# and extract the field.
- if fargs[0] in table._inherit_fields:
+ field = None
+ if field_path[0] in table._inherit_fields:
while True:
- field = working_table._columns.get(fargs[0])
+ field = working_table._columns.get(field_path[0])
if field:
self.__field_tables[i] = working_table
break
- next_table = working_table.pool.get(working_table._inherit_fields[fargs[0]][0])
+ next_table = working_table.pool.get(working_table._inherit_fields[field_path[0]][0])
if next_table not in self.__all_tables:
self.__joins.append('%s."%s"=%s."%s"' % (next_table._table, 'id', working_table._table, working_table._inherits[next_table._name]))
self.__all_tables.add(next_table)
working_table = next_table
# Or (try to) directly extract the field.
else:
- field = working_table._columns.get(fargs[0])
+ field = working_table._columns.get(field_path[0])
if not field:
if left == 'id' and operator == 'child_of':
ids2 = to_ids(right, table)
dom = child_of_domain(left, ids2, working_table)
self.__exp = self.__exp[:i] + dom + self.__exp[i+1:]
+ else:
+ # field could not be found in model columns, it's probably invalid, unless
+ # it's one of the _log_access special fields
+ # TODO: make these fields explicitly available in self.columns instead!
+ if field_path[0] not in MAGIC_COLUMNS:
+ raise ValueError("Invalid field %r in domain expression %r" % (left, exp))
continue
field_obj = table.pool.get(field._obj)
- if len(fargs) > 1:
+ if len(field_path) > 1:
if field._type == 'many2one':
- right = field_obj.search(cr, uid, [(fargs[1], operator, right)], context=context)
- self.__exp[i] = (fargs[0], 'in', right)
+ right = field_obj.search(cr, uid, [(field_path[1], operator, right)], context=context)
+ self.__exp[i] = (field_path[0], 'in', right)
# Making search easier when there is a left operand as field.o2m or field.m2m
if field._type in ['many2many', 'one2many']:
- right = field_obj.search(cr, uid, [(fargs[1], operator, right)], context=context)
- right1 = table.search(cr, uid, [(fargs[0], 'in', right)], context=context)
+ right = field_obj.search(cr, uid, [(field_path[1], operator, right)], context=context)
+ right1 = table.search(cr, uid, [(field_path[0],'in', right)], context=dict(context, active_test=False))
self.__exp[i] = ('id', 'in', right1)
if not isinstance(field, fields.property):
# the function field doesn't provide a search function and doesn't store
# values in the database, so we must ignore it : we generate a dummy leaf
self.__exp[i] = TRUE_LEAF
+ _logger.error(
+ "The field '%s' (%s) can not be searched: non-stored "
+ "function field without fnct_search",
+ field.string, left)
+ # avoid compiling stack trace if not needed
+ if _logger.isEnabledFor(logging.DEBUG):
+ _logger.debug(''.join(traceback.format_stack()))
else:
subexp = field.search(cr, uid, table, left, [self.__exp[i]], context=context)
if not subexp:
self.__exp[i] = ('id', o2m_op, select_distinct_from_where_not_null(cr, field._fields_id, field_obj._table))
elif field._type == 'many2many':
+ rel_table, rel_id1, rel_id2 = field._sql_names(working_table)
#FIXME
if operator == 'child_of':
def _rec_convert(ids):
if field_obj == table:
return ids
- return select_from_where(cr, field._id1, field._rel, field._id2, ids, operator)
+ return select_from_where(cr, rel_id1, rel_table, rel_id2, ids, operator)
ids2 = to_ids(right, field_obj)
dom = child_of_domain('id', ids2, field_obj)
else:
call_null_m2m = False
m2m_op = 'not in' if operator in NEGATIVE_TERM_OPERATORS else 'in'
- self.__exp[i] = ('id', m2m_op, select_from_where(cr, field._id1, field._rel, field._id2, res_ids, operator) or [0])
+ self.__exp[i] = ('id', m2m_op, select_from_where(cr, rel_id1, rel_table, rel_id2, res_ids, operator) or [0])
if call_null_m2m:
m2m_op = 'in' if operator in NEGATIVE_TERM_OPERATORS else 'not in'
- self.__exp[i] = ('id', m2m_op, select_distinct_from_where_not_null(cr, field._id1, field._rel))
+ self.__exp[i] = ('id', m2m_op, select_distinct_from_where_not_null(cr, rel_id1, rel_table))
elif field._type == 'many2one':
if operator == 'child_of':
if operator in NEGATIVE_TERM_OPERATORS:
res_ids.append(False) # TODO this should not be appended if False was in 'right'
return (left, 'in', res_ids)
-
- m2o_str = False
- if right:
- if isinstance(right, basestring): # and not isinstance(field, fields.related):
- m2o_str = True
- elif isinstance(right, (list, tuple)):
- m2o_str = True
- for ele in right:
- if not isinstance(ele, basestring):
- m2o_str = False
- break
- if m2o_str:
- self.__exp[i] = _get_expression(field_obj, cr, uid, left, right, operator, context=context)
- elif right == []:
- pass # Handled by __leaf_to_sql().
- else: # right is False
- pass # Handled by __leaf_to_sql().
+ # resolve string-based m2o criterion into IDs
+ if isinstance(right, basestring) or \
+ right and isinstance(right, (tuple,list)) and all(isinstance(item, basestring) for item in right):
+ self.__exp[i] = _get_expression(field_obj, cr, uid, left, right, operator, context=context)
+ else:
+ # right == [] or right == False and all other cases are handled by __leaf_to_sql()
+ pass
else:
# other field type
def __leaf_to_sql(self, leaf, table):
left, operator, right = leaf
+ # final sanity checks - should never fail
+ assert operator in (TERM_OPERATORS + ('inselect',)), \
+ "Invalid operator %r in domain term %r" % (operator, leaf)
+ assert leaf in (TRUE_LEAF, FALSE_LEAF) or left in table._all_columns \
+ or left in MAGIC_COLUMNS, "Invalid field %r in domain term %r" % (left, leaf)
+
if leaf == TRUE_LEAF:
query = 'TRUE'
params = []
query = '(%s OR %s."%s" IS NULL)' % (query, table._table, left)
elif check_nulls and operator == 'not in':
query = '(%s AND %s."%s" IS NOT NULL)' % (query, table._table, left) # needed only for TRUE.
- else: # Must not happen.
- pass
+ else: # Must not happen
+ raise ValueError("Invalid domain term %r" % (leaf,))
elif right == False and (left in table._columns) and table._columns[left]._type=="boolean" and (operator == '='):
query = '(%s."%s" IS NULL or %s."%s" = false )' % (table._table, left, table._table, left)
elif (operator == '=?'):
if (right is False or right is None):
+ # '=?' is a short-circuit that makes the term TRUE if right is None or False
query = 'TRUE'
params = []
- elif left in table._columns:
- format = table._columns[left]._symbol_set[0]
- query = '(%s."%s" = %s)' % (table._table, left, format)
- params = table._columns[left]._symbol_set[1](right)
else:
- query = "(%s.\"%s\" = '%%s')" % (table._table, left)
- params = right
+ # '=?' behaves like '=' in other cases
+ query, params = self.__leaf_to_sql((left, '=', right), table)
elif left == 'id':
query = '%s.id %s %%s' % (table._table, operator)
query = '(unaccent(%s."%s") %s unaccent(%s))' % (table._table, left, sql_operator, format)
else:
query = '(%s."%s" %s %s)' % (table._table, left, sql_operator, format)
- else:
- # Ugly case to support columns present in database but not in
- # _columns. This will probably be removed in the future, but
- # we have to keep it for now.
- _logger.warning("The domain term '%s' specify a column not declared in _columns." % ((left, operator, right),))
- if self.has_unaccent and sql_operator in ('ilike', 'not ilike'):
- query = "(unaccent(%s.\"%s\") %s unaccent('%s'))" % (table._table, left, sql_operator, right)
- else:
- query = "(%s.\"%s\" %s '%s')" % (table._table, left, sql_operator, right)
+ elif left in MAGIC_COLUMNS:
+ query = "(%s.\"%s\" %s %%s)" % (table._table, left, sql_operator)
+ params = right
+ else: # Must not happen
+ raise ValueError("Invalid field %r in domain term %r" % (left, leaf))
add_null = False
if need_wildcard:
add_null = not str_utf8
elif left in table._columns:
params = table._columns[left]._symbol_set[1](right)
- else:
- # Matching else clause for the above else clause, where the
- # params are actually already in the query.
- params = []
if add_null:
query = '(%s OR %s."%s" IS NULL)' % (query, table._table, left)
projects / odoo / odoo.git / blobdiff