1. 29 Jul, 2016 2 commits
  2. 28 Jul, 2016 2 commits
  3. 27 Jul, 2016 1 commit
  4. 25 Jul, 2016 2 commits
  5. 21 Jul, 2016 2 commits
  6. 19 Jul, 2016 3 commits
  7. 16 Jul, 2016 1 commit
    • Julien Muchembled's avatar
      HBTreeFolder2 fixes · c3450f14
      Julien Muchembled authored
      There's no magic in this patch series: it is known that HBTreeFolder2 has
      limitations about the ids that can be set without conflict, and this can't be
      fixed without causing compatibility issues with existing data.
      
      The patches contain:
      - some optimization
      - bug fixes
      - detection of id conflicts before causing data loss
      
      This will also allow us to use a newer version of ZODB. Recent BTrees failed
      on the following line of `_setOb`:
      
              if len(id_list) == 1 and not htree.has_key(None):
      
      (None is not valid key for comparison since
       ZODB commit bb5aac21277f43333d6450064dc6670c8c280e40)
      
      The long story about id conflicts is that a HBTreeFolder2 can't store 2 objects
      <A> and <A>-<B> where <A> does not contain '-', and that's the rule followed by
      _getOb/_setOb/_delOb. However:
      - Conflicts are detected by testing the type of the value, which means
        HBTreeFolder2 can't store values of the same type as the one it uses
        internally (i.e. OOBTree).
      - For performance reasons, _htree_iteritems and getTreeIdList use a stricter
        rule: they assume there can't be 2 objects <A> and <A>-<B>, regardless of the
        presence of a separator in <A>. Maybe this rule should be enforced in _setOb.
      
      /reviewed-on nexedi/erp5!112
      c3450f14
  8. 15 Jul, 2016 13 commits
  9. 14 Jul, 2016 6 commits
  10. 13 Jul, 2016 3 commits
  11. 12 Jul, 2016 2 commits
  12. 11 Jul, 2016 1 commit
    • Douglas's avatar
      erp5_data_notebook: environment object implementation and refactoring to ERP5 kernel · a0d21451
      Douglas authored
      @Tyagov review, please. I'm creating a test suite now and will post about the test results as soon as they are available. 
      
      - An environment object was implemented to help us deal with the multiprocess
      architecture of ERP5 and objects that cannot be easily stored in the ZODB.
      It stores definition of functions, classes and variables as string. The implementation
      uses a dumb Environment class to allow users to make `define` and `undefine` calls,
      which are captured and processed by an AST transformer before code execution.
      
      - Along with the environment object, an automatic "import fixer" was created. It does
      not allow users to import modules as they normally would, because this may cause
      collateral effects on other users' code. A good example is the plot settings in the
      matplotlib module. It will fix normal imports, make them use the environment object
      mentione earlier automatically and warn the user about it.
      
      Some bugs were fixed with this new implementation: 
      
      - https://nexedi.erp5.net/bug_module/20160318-7098DD, which reports an inconsistency
      on portal catalog queries between Jupyter and Python (Script) objects. Probably an
      issue with user context storage in ActiveProcess
      
      - https://nexedi.erp5.net/bug_module/20160330-13AA193, which reports an error related
      to acquisition when trying to plot images, which happened in other situations, although
      this is not officially reported in Nexedi's ERP5. This probably also was happening because
      of old user context storage.
      
      
      /reviewed-on nexedi/erp5!131
      a0d21451
  13. 08 Jul, 2016 2 commits
    • Douglas's avatar
      erp5 kernel: improved detection of variables from user context that cannot be put in the zodb · 23e06437
      Douglas authored
      Variables are investigated, recursively in case of container objects (like lists, for example),
      to detect if they can be stored in the ZODB.
      In this investigation persistent objects are identified by being an instance of the object
      class and implementing a `__getstate__` method that raises no exception. If the variable is
      not a Persistent object then we try to pickle and load it.
      
      While developing the pickleable object identification a complication was found. It seems that
      the code cannot capture cPickle.PicklingError in the usual way, `except cPickle.PicklingError`.
      It's consequence of some weirdness with regards to pickle/cPickle modules exceptions classes and
      more about it can be read at http://bugs.python.org/issue1457119. So, the workaround for this complication
      was to catch all exceptions and check the exception class name as string.
      
      The whole check for zodb persistence was moved into an utility function for the sake of readability
      and code maintenance.
      
      The Base_executeJupyter script object was transformed into an extension to be able to properly handle
      transaction errors and render them correctly inside Jupyter.
      23e06437
    • Sebastien Robin's avatar
      erp5_core: optimize jump to related object when jumping to a module · fb52f4a5
      Sebastien Robin authored
      Avoid getting all related values when we jump to a module.
      fb52f4a5