Thu, 25 Apr 2013 13:34:48 +0200 [notification] move notification view in ``sobject.notification``
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 25 Apr 2013 13:34:48 +0200] rev 8931
[notification] move notification view in ``sobject.notification`` It has no user outside this module. This enforce serversideness of notification and allow future cleanup. No backward compat is set up to prevent circular import. The class has no other user anyway. (closes 2845144)
Thu, 25 Apr 2013 14:10:55 +0200 remove unused import
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 25 Apr 2013 14:10:55 +0200] rev 8930
remove unused import pyflakes say they are unused. Tests suite confirms.
Thu, 25 Apr 2013 17:30:09 +0200 one more merge
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 25 Apr 2013 17:30:09 +0200] rev 8929
one more merge
Thu, 25 Apr 2013 16:10:56 +0200 [notification] introduce an official `notify_on_commit` function
Sylvain Thénault <sylvain.thenault@logilab.fr> [Thu, 25 Apr 2013 16:10:56 +0200] rev 8928
[notification] introduce an official `notify_on_commit` function It provides a proper notification api instead of replacing it by yet another clumsy one. Closes #2837251
Thu, 25 Apr 2013 10:57:01 +0200 [cubicweb/doc] Replace dc_type() by cw_etype
Vladimir Popescu <vladimir.popescu@logilab.fr> [Thu, 25 Apr 2013 10:57:01 +0200] rev 8927
[cubicweb/doc] Replace dc_type() by cw_etype dc_type() is may be translated. Leading to terrible terrible damage.
Thu, 04 Apr 2013 11:58:41 +0200 [dataimport] backout 6947201033be (related to #2788402)
Vladimir Popescu <vladimir.popescu@logilab.fr> [Thu, 04 Apr 2013 11:58:41 +0200] rev 8926
[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.
(0) -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 tip