1. 28 Apr, 2010 2 commits
  2. 12 Apr, 2010 2 commits
    • Sylvain Thénault's avatar
      [storage] missing qrefresh in previous patch applied: fix comment, error... · 35d44017c72b
      Sylvain Thénault authored
      [storage] missing qrefresh in previous patch applied: fix comment, error message, and use a storage specified encoding, not cubicweb's encoding
      branch : stable
    • Pierre-Yves David's avatar
      [fix] fix path unicity process in BytesFileSystemStorage.new_fs_path · aebd00a2d316
      Pierre-Yves David authored
      The previous implementation was bugged (prefixing the whole path with '_'
      instead of the base name). A new version (using number) replace it.
      * * *
      Improve BytesFileSystemStorage.new_fs_path to use available metadata
      This version try to get some hint about how to name the file using metadata.
      Using the real file name and extension when available.  Keeping the extension
      might be usefull for exemple in the case of processing that use filename
      extension to detect content-type.
      branch : stable
  3. 08 Apr, 2010 1 commit
  4. 02 Apr, 2010 1 commit
    • Adrien Di Mascio's avatar
      [storages] fix fs_importing side-effect on entity.data · 88b5ca8da928
      Adrien Di Mascio authored
      When creating a new File object, if fs_importing is set,
      we want entity.data to be the file content instead of the
      filepath for the rest of the transaction.
      (see test_bfss_fs_importing_transparency) for test implementation
      To make this possible, the storage hooks (entity_added / entity_updated)
      must return the correct value to set in the entity dict.
      branch : stable
  5. 25 Mar, 2010 2 commits
    • Sylvain Thénault's avatar
      [source storage] refactor source sql generation and results handling to allow... · ad91f93bbb93
      Sylvain Thénault authored
      [source storage] refactor source sql generation and results handling to allow repository side callbacks
      for instance with the BytesFileSystemStorage, before this change:
      * fspath, _fsopen function were stored procedures executed on the database
        -> files had to be available both on the repository *and* the database host
      * we needed implementation for each handled database
      Now, those function are python callbacks executed when necessary on the
      repository side, on data comming from the database.
      The litle cons are:
      * you can't do anymore restriction on mapped attributes
      * you can't write queries which will return in the same rset column
        some mapped attributes (or not mapped the same way) / some not
      This seems much acceptable since:
      * it's much more easy to handle when you start having the db on another host
        than the repo
      * BFSS works seemlessly on any backend now
      * you don't bother that much about the cons (at least in the bfss case):
        you usually don't do any restriction on Bytes...
      Bonus points: BFSS is more efficient (no queries under the cover as it
      was done in the registered procedure) and we have a much nicer/efficient
      fspath implementation.
      IMO, that rocks :D
      branch : stable
    • Sylvain Thénault's avatar
      [bfss] fix name error · 9c4ea944ecf9
      Sylvain Thénault authored
      branch : stable
  6. 19 Mar, 2010 1 commit
    • Adrien Di Mascio's avatar
      [source] implement storages right in the source rather than in hooks · d9e8af8a7a42
      Adrien Di Mascio authored
      The problem is that Storage objects will most probably change entity's
      dictionary so that values are correctly set before the source's
      corresponding method (e.g. entity_added()) is called.
      For instance, the BFSFileStorage will change the original binary
      data and replace it with the destination file path in order to store
      the file path in the database. This change must be local
      to the source in order not to impact other hooks or attribute access
      during the transaction, the whole idea being that the same
      application code should work exactly the same whether or not a
      BFSStorage is used or not.
  7. 08 Mar, 2010 1 commit
  8. 26 Feb, 2010 1 commit
  9. 08 Feb, 2010 1 commit
  10. 26 Jan, 2010 1 commit
  11. 22 Jan, 2010 2 commits
    • Sylvain Thénault's avatar
      add a reminder · 815e08c53548
      Sylvain Thénault authored
    • Sylvain Thénault's avatar
      first draft for a simple hooks based custom attribute storage, · f65743cc53e4
      Sylvain Thénault authored
      with a BytesFileSystemStorage POC implementation.
      * a dictionary contains maps from which attribute of which entity types are
        mapped to which custom storage
      * hooks check for one of these entity type being added/modified/deleted
      * read is based on the sql generator callback mecanism (used in vcsfile for
      * all storages have the same basic interface (read, add, update, delete),
        and should be pluggable in a transparent way (except at migration time
        when one want to change from a storage to another)
      * the sample BytesFileSystemStorage:
        * may store Bytes attributes content of any entity type as file on the file system
        * is based on one FSPATH rql/sql function and another _fsopen only available in sql
        * has a dumb file name allocation algorithm