[dataimport] backout 6947201033be (related to #2788402)
(and add a try: except to cache the intended error)
The problem actually comes from the ``MassiveObjectStore``
in the ``dataio`` cube, so it should be corrected there.
Here, we only protect it with a ``RuntimeWarning`` so that
the user can see the problem.
``value`` is set to ``None`` (whence to ``NULL`` from
a database standpoint), so that the data can be nevertheless
inserted in the database. However, only the keys present in
``row`` are actually non-'``NULL``'.
The real solution is to work out the issue in ``MassiveObjectStore``
directly.
The current try/except should only be a temporary hack.
# copyright 2003-2012 LOGILAB S.A. (Paris, FRANCE), all rights reserved.
# contact http://www.logilab.fr/ -- mailto:contact@logilab.fr
#
# This file is part of CubicWeb.
#
# CubicWeb is free software: you can redistribute it and/or modify it under the
# terms of the GNU Lesser General Public License as published by the Free
# Software Foundation, either version 2.1 of the License, or (at your option)
# any later version.
#
# CubicWeb is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
# FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more
# details.
#
# You should have received a copy of the GNU Lesser General Public License along
# with CubicWeb. If not, see <http://www.gnu.org/licenses/>.
"""server side objects"""
import os.path as osp
def registration_callback(vreg):
vreg.register_all(globals().itervalues(), __name__)
global URL_MAPPING
URL_MAPPING = {}
if vreg.config.apphome:
url_mapping_file = osp.join(vreg.config.apphome, 'urlmapping.py')
if osp.exists(url_mapping_file):
URL_MAPPING = eval(file(url_mapping_file).read())
vreg.info('using url mapping %s from %s', URL_MAPPING, url_mapping_file)