Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File paths now respect tar spec + add n-quads #2459

Merged
merged 2 commits into from May 20, 2021

Conversation

imsdu
Copy link
Contributor

@imsdu imsdu commented May 19, 2021

Fixes #2412
Fixes #2363

Also:

  • Use the proper extension for n-triples, n-quads and dot
  • For generated paths, distribute the files according to the resource representation or if it is a file to be able to fetch both the source and the compacted form for example and to identify them better.

@imsdu imsdu marked this pull request as ready for review May 19, 2021 13:15
(
visitedPaths ++ reference.path,
duplicates ++ reference.path.filter(visitedPaths.contains),
invalids ++ reference.path.filterNot(validatePath),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we differentiate between invalids and longIds? Aren't both invalid paths? I don't think we need this detail here.

A path is wrong if the filename is greater than 100 or if the whole path is greater than 255

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The long ids is only a concern if you don't provide a valid path.
The invalid paths are about the ones provided by the users that are rejected.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In both cases the client would have to adapt the path, that's why I didn't see the need to treat that separately.
But if you think is clearer for the client with the custom rejections, that's fine too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The broken rule is not the same and the error message is not the same.
If you look at the rejection, the error message is generated according to the broken rules in order to try to be not too verbose.

@umbreak
Copy link
Contributor

umbreak commented May 19, 2021

the fact that we reject immediately is fine now, since we only offer tar. However, if we were to support zip for example, we wouldn't want to reject at this stage, but when fetching

@umbreak umbreak self-requested a review May 20, 2021 08:28
@imsdu imsdu merged commit 28bf345 into BlueBrain:master May 20, 2021
@imsdu imsdu deleted the 2412-2363-path-tar-n-quads branch May 20, 2021 09:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants