Skip to content

FILE_SEARCH_AT Order in Level 4 #7

@vinlin24

Description

@vinlin24

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]

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions