[Zeitgeist] [Bug 954206] Re: Improved DELETE_EVENT handling
** 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 ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 954206] Re: Improved DELETE_EVENT handling
** 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 + * 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= + * Also, would a current_origin field be useful? -- 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? To manage notifications about this bug go to: https://bugs.launchpad.net/zeitgeist/+bug/954206/+subscriptions ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
