#41: update_one tests
#52
Conversation
| }; | ||
| let path_buf = CanonicalPathBuf::canonicalize(&file_path).unwrap(); | ||
| let update = actual | ||
| .update_one(path_buf.clone(), old_id) |
There was a problem hiding this comment.
Now I'm curious what happens if a user of the lib passes wrong old_id...
| let update = actual | ||
| .update_one(path_buf.clone(), old_id) | ||
| .expect("Should update one resource correctly"); | ||
| }); |
There was a problem hiding this comment.
In this current scenario, the update should be empty (nothing changed).
Probably reasoning with paths instead of files would be better here:
- If we remove a file with id
id1and pathpath1then the update isdeleted(id1) - If we modify a file by path
path1so it's new id isid2then the update isdeleted(id1), added(id2) - If we rename/move a file with
id1frompath1topath2then the update isdeleted(id1), added(id1)
Please, double-check.
There was a problem hiding this comment.
Notion of a "file" is confusing here because it is combination of path and content, but index works with paths and contents separately. A "resource" is an identified content, a "path" it's current location.
| @@ -904,4 +904,23 @@ mod tests { | |||
| assert!(new2 > old2); | |||
| assert!(new2 > new1); | |||
| } | |||
|
|
|||
There was a problem hiding this comment.
Idea for a test case:
- Build the index of folder with paths e.g.
root/Aandroot/B. - Create file by path
root/C. - Call
update_one("root/C", id).
Two cases:
a)idmatches the content of new resource
b)iddoes not - What should be the result?
There was a problem hiding this comment.
Nice, alright. Should it replace the current one or is it a new unittest?
|
Should we create new struct for the error So, if the caller doesn't have information that the resource changed, it's a mistake to call this method. But if the resource was changed indeed (timestamp must be changed, too) and new content has same size and same CRC-32 hash — then it's a collision indeed. We can also split single error into two different errors for clarity, depending on was the timestamp changed or not. |
|
Superseded by #72 |
update_allandupdate_oneare consistent #41