1. 05 Dec, 2014 4 commits
  2. 07 Nov, 2014 5 commits
  3. 27 Oct, 2014 1 commit
  4. 30 Jul, 2014 5 commits
  5. 25 Jul, 2014 2 commits
  6. 24 Jul, 2014 4 commits
  7. 22 Jul, 2014 1 commit
  8. 08 Jul, 2014 4 commits
  9. 04 Jul, 2014 5 commits
  10. 26 Jun, 2014 1 commit
  11. 24 Jun, 2014 2 commits
  12. 20 Jun, 2014 3 commits
  13. 19 Jun, 2014 3 commits
    • client: in iterator records, export data serial as stored by NEO · e76af297
      There is simply no way to guess data serials and instead of producing random
      values, the only solution is to retrieve the values from storages.
      
      There are still differences for data serials between FileStorage and NEO:
      - NEO always resolves to original serial, to avoid any indirection
        (which slightly speeds up undo at the expense of a more complex pack code)
      - NEO does not make any difference between object deletion and creation undone
        (data serial always null in storage)
      It has to be decided whether NEO implementation should be changed about this.
      
      Apart from that, conversion database back from NEO should be fixed.
      testExportFileStorageBug passes and there was in fact no FileStorage bug.
      
      Another change is that iterator does not trash the client cache anymore.
      Julien Muchembled committed
    • client: simplify iterator · 441145e5
      Julien Muchembled committed
    • storage: refactoring & cleanup · bd03b14b
      - _[gs]etPackTID accessors implementation is not backend-specific
        so move them to superclass
      - _getObjectLength method is useless since data_tid always contains the wanted
        information, regardless the contents of value_tid column
      Julien Muchembled committed