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.path -> file.paths #140

Closed
samuelstroschein opened this issue Aug 23, 2024 — with Linear · 0 comments
Closed

file.path -> file.paths #140

samuelstroschein opened this issue Aug 23, 2024 — with Linear · 0 comments

Comments

Copy link
Member

samuelstroschein commented Aug 23, 2024

Context

We know that files should be "duplicated"/symliked in a lix in a the future.

unblocks use cases like "this markdown file should be stored in /dev-rel/intro.md for writing and /source-code/website/static/blog/intro.md for ease of publishing"

Proposal

We could define a file.path as a relation to FilePaths. A file id points to a list of file paths. Each file path must be unique. (Don't forget, we can use FOREIGN Keys to ensure consistency LIX-134)

  • (+) get the data structure "right" from the get go to enable
  • (-) risk of not getting it right :D

Migration is simpler from N -> 1. Than 1 -> N.

The risk of defining a file path as singular seems higher than defining it as multiple. A system that can handle one file under N paths is able to handle a (migrated) system that can handle a file with 1 path.

samuelstroschein added a commit to opral/monorepo that referenced this issue Aug 30, 2024
On conflict methods are otherwise not possible. And, it's logical that a path should be unique (as long as we have a "a file only has one path" constraints opral/inlang-sdk#140)
@martin-lysk martin-lysk closed this as not planned Won't fix, can't repro, duplicate, stale Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants