mengw15 commented on code in PR #6502:
URL: https://github.com/apache/texera/pull/6502#discussion_r3770420670
##########
amber/src/main/python/pytexera/storage/dataset_file_document.py:
##########
@@ -56,20 +58,29 @@ def __init__(self, file_path: str):
Parses the file path into dataset metadata.
:param file_path:
- Expected format -
"/ownerEmail/datasetName/versionName/fileRelativePath"
- Example:
"/[email protected]/twitterDataset/v1/california/irvine/tw1.csv"
+ Expected format -
+ "/datasets/ownerEmail/datasetName/versionName/fileRelativePath"
+ Example:
+ "/datasets/[email protected]/twitterDataset/v1/california/tw1.csv"
"""
parts = file_path.strip("/").split("/")
- if len(parts) < 4:
+
+ if len(parts) < 5:
raise ValueError(
Review Comment:
One migration gap worth adding to the body's "Known migration limits": a
user Python UDF that hardcodes a pre-prefix path in its own code —
`DatasetFileDocument("/[email protected]/ds/v1/f.csv")` — was working before this
change and now raises here, and `36.sql` can't help because it rewrites only
the `fileName` / `datasetVersionPath` JSON properties, never user code strings.
Unlike the renamed/deleted-dataset case (already broken paths), these were
live. Rewriting user code in a migration would be wrong, so documenting it
(body + release note) seems like the right treatment. Not blocking.
Also, while you're editing the description: it still refers to
`sql/updates/30.sql` in three places — the file is `36.sql`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
