"File" stereotype :deletion of file, problem of relpicated MD
|Assignee:||Battaglia Marc||% Done:|
Problem with "File" stereotype:
If we replicate a metadata with an existing linked file, then the replicated metadata can delete the file of the original.
This is not an important issue for us (we can disable the deletion on file), but we must not reproduce it in V4.
#8 Updated by Blatti Yves about 5 years ago
I see multiple ways of fixing it (and there's certainly many other, we'll have to discuss them)
1. "The XML way" : on replication, parse XML for "locally attached items", if found, duplicate the files with a new name, and replace the links.
2. "The Filesystem way" : we choose to name attachment with MD identifiers (prefix), or place them in an identified folder (let's say .../media/easysdi/images/md_guid/uniquefilename.ext), when we replicate a metadata, we replicate all the files with the prefix OR the whole folder related to the metadata.
3. "The dirty way" : on deletion of an attachment (of a replicated metadata), we don't delete the file, it stays on the system, so the "original" metadata keeps pointing on it
Let's compare them:
|Method||Ease of implementation||"Beauty"||Migration/Update problem||remark|
|1. "The XML way"||--||++||no problem with existing data||Looks a bit heavy to solve a small problem...|
|2. "The Filesystem way"||+||+||we'd have to parse all existing MD and rename or move attachments||Looks like a good compromise but, the update is a problem|
|3. "The dirty way"||++||--||no problem with existing data
(but problems in the future... with orphaned files...)
|could be used temporarily, waiting for a clean fix|
Other (better) solutions/proposals welcome ! ;-)