Conversation
| { | ||
| URI uri = FileUtil.createUri(filePath); | ||
| if (FileUtil.FILE_SCHEME.equals(uri.getScheme())) | ||
| return new File(uri); |
There was a problem hiding this comment.
@labkey-matthewb Do you have any suggestions how to get around using new File and maybe use FileLike here? In order for f.isAbsolute() to work for path that starts with file:/, I had to convert string to uri first before passing to File constructor.
There was a problem hiding this comment.
If you are stuck in File land, use FileUtil.appendPath() and FileUtil.appendName() instead of new File(File,String).
To get out of File land, you have to start with getting FileLike for the directories you expect to find the files in. E.g. PipeRoot.getRootFileLike() instead of PipeRoot.getPath(). Also PipeRoot has useful resolve() methods and isUnderRoot() methods.
There was a problem hiding this comment.
I should have rewritten this whole class to be ExpDataFileLikeConverter and killed usages convert(File.class). Lets leave that cleanup for a separate PR.
| @@ -218,49 +219,101 @@ public Object convert(Class type, Object value) | |||
| User user = (User) QueryService.get().getEnvironment(QueryService.Environment.USER); | |||
| Object fileRootPathObj = QueryService.get().getEnvironment(QueryService.Environment.FILEROOTPATH); | |||
There was a problem hiding this comment.
Consider putting a FileLike in the environment instead of a String? I don't love that we're using QueryService.get/setEnvironment() here, but that's a problem for another time.
There was a problem hiding this comment.
2nd thought. Can we refactor this so there is a public convert() method that takes (user, fileRootPath, assayFilesPath) and then have _convert() call that method with these values? Then we could have QUS and DataLoader call that method directly. Other usages could still use still rely on thread-local storage until/unless we remove this from ConvertUtils.
There was a problem hiding this comment.
I changed this to a static method that can be called directly. Currently there are 3 usages for importing assay results that could be refactored to use this static method. However, I didn't go ahead with the refactoring due to the much entangled run/result association. If we are removing this from ConvertUtils for sure then that's an effort worth trying. I've added a TODO comment.
There was a problem hiding this comment.
Changes made to no longer register ExpDataFileConverter for File.class
| { | ||
| // Interpret relative paths based on the file root | ||
| f = new File(root.getRootPath(), f.getPath()); | ||
| fileUnderRoot = new File(root.getRootPath(), f.getPath()); |
There was a problem hiding this comment.
FileUtil.appendPath()
There was a problem hiding this comment.
Unfortunately switching to FileUtil.appendPath broke valid relative path such as "../@files/test.txt". But maybe we can just say this is not supported.
# Conflicts: # study/test/src/org/labkey/test/tests/study/StudyDatasetFileFieldTest.java
labkey-matthewb
left a comment
There was a problem hiding this comment.
I'm not sure I can track all the subclasses here, but this looks like a good step forward. I only have one question about files that exists on disk, but aren't in a known file root. Would getFileName() benefit from having a structured return value?
And the tests will be super helpful.
| } | ||
|
|
||
| // use File converter for known file fields even if inferTypes = false. If inferTypes, this is already done. | ||
| if (!getInferTypes()) |
There was a problem hiding this comment.
I think this is where I get lost. Why do we we rely on this? I would hope that import would always work with no conversion in DataLoader. (AFAIK, the only code that "should" rely on this is currently the infer type UI)
| FileImageRenderHelper renderHelper = createRenderHelper(ctx, url, filename, displayName, fileIconUrl, popupIconUrl, thumbnail, isImage); | ||
| String displayName = getFileName(ctx, fileValue); | ||
| boolean unavailable = displayName.endsWith(UNAVAILABLE_FILE_SUFFIX); | ||
| String url = null == s || unavailable ? null : s.eval(ctx); |
There was a problem hiding this comment.
Nice check here. It would be nice if getFileName() had an explicit structured return (e.g. record(String fileDisplay,Boolean available), but this is workable. I wonder about the case in FileLinkDisplayColumn where we fall back to result = f.getName() when we don't find the file in an expected "file root".
What is the expected behavior in this case? Should we treat as "unavailable"? Should we render a URL?
There was a problem hiding this comment.
In the case of result = f.getName() when we fail to find file in root, valid is false, and the "unavailable" suffix will be added.
I added selenium test for grid and update view for LKS unavailable file both due to invalid path (exists but out side of file root) and absent file (file deleted after upload) in this commit
Rationale
This PR include the following changes:
Related Pull Requests
Changes