-
Notifications
You must be signed in to change notification settings - Fork 44
Open
Description
The tested operations for Level 4:
self.test_data_4 = [
["FILE_UPLOAD_AT", "2021-07-01T12:00:00", "Initial.txt", "100kb"],
["FILE_UPLOAD_AT", "2021-07-01T12:05:00", "Update1.txt", "150kb", 3600],
["FILE_GET_AT", "2021-07-01T12:10:00", "Initial.txt"],
["FILE_COPY_AT", "2021-07-01T12:15:00", "Update1.txt", "Update1Copy.txt"],
["FILE_UPLOAD_AT", "2021-07-01T12:20:00", "Update2.txt", "200kb", 1800],
["ROLLBACK", "2021-07-01T12:10:00"],
["FILE_GET_AT", "2021-07-01T12:25:00", "Update1.txt"],
["FILE_GET_AT", "2021-07-01T12:25:00", "Initial.txt"],
["FILE_SEARCH_AT", "2021-07-01T12:25:00", "Up"],
["FILE_GET_AT", "2021-07-01T12:25:00", "Update2.txt"]
]
And the expected output for the FILE_SEARCH_AT
operation:
found at [Update1.txt, Update1Copy.txt, Update2.txt]
Why is Update2.txt
at the end? According to the description of FILE_SEARCH
from Level 2:
- FILE_SEARCH(prefix)
- Find top 10 files starting with the provided prefix. Order results by their size in descending order, and in case of a tie by file name.
Sorting by size descending is the primary sort key. From the test data, Update2.txt
has the largest size (200 kB), followed by Update1.txt
and UpdateCopy.txt
(150 kB, which are themselves ordered ascending by their name as the secondary sort key).
Should the expected output not instead be:
found at [Update2.txt, Update1.txt, Update1Copy.txt]
timinar, qirh, 0xmmo, tanneraslan, casey-chow and 2 more
Metadata
Metadata
Assignees
Labels
No labels