| 2012-03-13 16:40:20 |
Siegfried Gevatter |
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= |
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? |
|
| 2012-03-18 12:20:41 |
Siegfried Gevatter |
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? |
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. |
|
