zeitgeist team mailing list archive

[Siegfried Gevatter <rainct@xxxxxxxxxx>]

** Description changed:

  DELETE EVENTS
  ============================================
  
  PRESENTATION
  
  When it comes to handling the deletion of files (local or remote
  -FTP/SSH/etc-), Zeitgeist supports the logging of DELETE_EVENTs, but
  that's about it.
  
  There's no clear distinction between what exists and what doesn't. The
  addition of the current_uri field made this worse, since if a file X is
  deleted and at some later point a new file is created with the same name
  they will be considered the same.
  
  PROPOSAL
  
  I propose two measures that should give us some pretty reasonable
  handling of deletions:
  
  a) Extend the StorageMonitor extension with a concept of "deleted
  resource". Insertion of DELETE_EVENTs (for local files, and possible
  ftp/sftp/etc) will update the value of "storage" where appropriate so
  the deleted events will be filtered out when querying with
  StorageState.AVAILABLE.
  
  b) In the engine itself, process DELETE_EVENTs by updating the
  "current_uri" of relevant subjects. The new URI will take a form like
  "deleted://%d" where %d is an identifier unique for each deletion
  (incremental integer, most likely).
  
  RANDOM (UNRELATED) THOUGHTS
  
   * This just made me think, would it make sense to add a new "resource"
  table for data shared between subjects (ie. current_uri and storage)?
  
   * Also, would a current_origin field be useful?
+ 
+ SEE ALSO
+ 
+ Related to this, please also check my proposal for improved MOVE_EVENT
+ handling in bug #778140.

-- 
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.
https://bugs.launchpad.net/bugs/954206

Title:
  Improved DELETE_EVENT handling

Status in Zeitgeist Framework:
  New

Bug description:
  DELETE EVENTS
  ============================================

  PRESENTATION

  When it comes to handling the deletion of files (local or remote
  -FTP/SSH/etc-), Zeitgeist supports the logging of DELETE_EVENTs, but
  that's about it.

  There's no clear distinction between what exists and what doesn't. The
  addition of the current_uri field made this worse, since if a file X
  is deleted and at some later point a new file is created with the same
  name they will be considered the same.

  PROPOSAL

  I propose two measures that should give us some pretty reasonable
  handling of deletions:

  a) Extend the StorageMonitor extension with a concept of "deleted
  resource". Insertion of DELETE_EVENTs (for local files, and possible
  ftp/sftp/etc) will update the value of "storage" where appropriate so
  the deleted events will be filtered out when querying with
  StorageState.AVAILABLE.

  b) In the engine itself, process DELETE_EVENTs by updating the
  "current_uri" of relevant subjects. The new URI will take a form like
  "deleted://%d" where %d is an identifier unique for each deletion
  (incremental integer, most likely).

  RANDOM (UNRELATED) THOUGHTS

   * This just made me think, would it make sense to add a new
  "resource" table for data shared between subjects (ie. current_uri and
  storage)?

   * Also, would a current_origin field be useful?

  SEE ALSO

  Related to this, please also check my proposal for improved MOVE_EVENT
  handling in bug #778140.

To manage notifications about this bug go to:
https://bugs.launchpad.net/zeitgeist/+bug/954206/+subscriptions