1. 28 Sep, 2016 1 commit
    • Sylvain Thénault's avatar
      [massive store] Follow configuration of the metadata generator · 307d96c0ab5a
      Sylvain Thénault authored
      Don't drop constraints and indexes for tables that are ignored by the metadata
      generator given to the store. One may now easily disable insertion of e.g.
      created_by / owned_by by removing them from the MetadataGenerator.META_RELATIONS
      set, in which case indexes for associated table won't be removed by the massive
  2. 17 Oct, 2016 1 commit
  3. 28 Sep, 2016 1 commit
    • Sylvain Thénault's avatar
      [massive store] Rework constraint/index handling · 9847a097266e
      Sylvain Thénault authored
      The basic idea is to keep the primary constraint on entities.eid since it's
      heavily used in metadata insertions. Other option would have been to drop /
      recreate but its very costly on big database, and the index is used for
      insertion into the entities table itself, so it's not worth droping it at a
      first glance.
      Also, keeping it avoids to systematically drop all constraints which depends on
      it. We may thus now lazily drop constraints, only on insertion of some
      etype/rtype for the related table.
      Related to #15538359
  4. 27 Sep, 2016 1 commit
    • Sylvain Thénault's avatar
      [massive store] Lazy removal of constraints and metadata indexes · 5b535fe2f364
      Sylvain Thénault authored
      They should not be removed during store's init, because we may want to query the
      database with its index between store creation and call to prepare_insert* (e.g.
      to build the extid2eid map).
      Along the way:
      * rename drop_metadata_constraints into drop_metadata_indexes, because that's
        what it does
      * rework a bit impacted tests
      Closes #15538359
  5. 17 Oct, 2016 1 commit
  6. 06 Oct, 2016 1 commit
  7. 05 Oct, 2016 1 commit
    • Sylvain Thénault's avatar
      [repository] Drop the entities.extid column and associated cache · 51c160677afe
      Sylvain Thénault authored
      This was not necessary anymore with promoted usage of the new data import API.
      Turn repository's _type_extid_cache to _type_cache with only the entity's type
      as key.
      This introduces an backward incompatible change: entity_metas dict doesn't
      contains anymore the extid key, but it doesn't seem used at all anywhere, so
      this sounds acceptable.
      Closes #15538317
  8. 30 Sep, 2016 1 commit
  9. 29 Sep, 2016 1 commit
  10. 17 Oct, 2016 1 commit
  11. 06 Oct, 2016 1 commit
  12. 11 Oct, 2016 1 commit
  13. 06 Oct, 2016 1 commit
  14. 30 Sep, 2016 1 commit
    • Sylvain Thénault's avatar
      flake8 and all · 432f87a63057
      Sylvain Thénault authored
      * update some copyright
      * drop most __docformat__ declaration
      * fix some flake8 warnings / errors
  15. 05 Oct, 2016 1 commit
  16. 01 Oct, 2016 1 commit
  17. 06 Oct, 2016 1 commit
  18. 30 Sep, 2016 3 commits
  19. 29 Sep, 2016 1 commit
    • Sylvain Thénault's avatar
      Drop deprecated LDAP related script · efb8250e37fb
      Sylvain Thénault authored
      both are relying on the 'entities.source' column which has been dropped in 3.19.
      They have been written with the old ldapsource in mind, which has been dropped at
      that time.
  20. 30 Sep, 2016 1 commit
    • Sylvain Thénault's avatar
      [entity] Stop linking to external site for external entities · 7b7108eb8178
      Sylvain Thénault authored
      This behaviour was ok when we had "true" multi-sources but its rather painful
      with datafeed sources. Also, it makes absolute_url() costlier than what it
      should. Besides, it relies on cw_metainformation()['source'] that is pending for
      Instead, add a link to the original object in the metadata view (the one that
      displays eid and source at the bottom right corner of the primary view).
      Related to #15538288.
  21. 29 Sep, 2016 2 commits
  22. 30 Sep, 2016 2 commits
    • Sylvain Thénault's avatar
      [repository] Drop deprecated extid2eid API and friends · 60fed6272771
      Sylvain Thénault authored
      This will break cwxmlparser based sources. They should be rewritten using a
      specific parser, based on xml representation or on rqlio. This is harsh but
      allows a so big cleanup of the code base.
      Furthermore, it's necessary for asource/extid handling in the entities table
      which is costly for most app that don't care at all about that...
      In this cset, delete:
      * all extid2eid methods
      * repo._extid_cache handling
      * [before/after]_entity_insertion source callback
      * the cwxmlparser
      and update related tests, notably unittest_datafeed where 'repull' testing has
      been removed, since it's now handled by the dataimport API and should not be
      retested there.
      Related to #15538288
      Closes #15538383
    • Sylvain Thénault's avatar
      [ldap] Stop using entities table in ldap source authentication and parser · 96ced95e4002
      Sylvain Thénault authored
      We may used cwuri for the same purpose, and do one more step towards deletion of
      entities.extid column.
      Related to #15538288
  23. 26 Oct, 2016 1 commit
  24. 03 Nov, 2016 1 commit
    • Denis Laxalde's avatar
      [tox] Require ldap3 < 2 for server tests · cf24ccbc7b83
      Denis Laxalde authored
      Apparently we are using some constants that got dropped/moved in ldap3 >=
      2.0.0 (which came out last week). So stay with version 1.4 until this gets
      sorted out.
  25. 02 Nov, 2016 1 commit
  26. 26 Oct, 2016 1 commit
  27. 28 Sep, 2016 1 commit
  28. 30 Sep, 2016 2 commits
  29. 24 Oct, 2016 6 commits
  30. 16 Aug, 2016 1 commit
    • Denis Laxalde's avatar
      [web] Clear "pending_others" session key after all relations got processed · 8f264d98d6fd
      Denis Laxalde authored
      The RelationField appends data to "pending_others" key while processing its
      posted information, but this key may already have been removed by the edit
      controller. So remove the key from session data only when all "others"
      relations have been processed using a while loop.
      A test case would be nice, but I could not build one easily unfortunately.
      Closes #4354551.