melinath
commented
7 years ago This would be a great change. It would be awesome to have a PR for it. A couple additional things:
- We'd like to switch over to hashes for everyone, rather than having a setting for it. It's just a better way to generate the folder hierarchy, because of the folder size issue. Old data will be preserved in the db if people want it to be.
- While we're at it, we could change the base folder from
daguerretodg- it's unlikely to be used by other applications and would free up space in the field for additional folder levels without needing to lengthen the field.
fitodic
The current save plan is to save image variations under a path based on the date they were created. This behaviour is more than satisfactory in most cases, such as using the library from the beginning of a project or incorporating it in the middle of a project. However, projects get migrated.
One issue we have encountered is the recreation of a large amount of image variations from the original set of images in a single run, i.e. on the same day. Theoretically, an unlimited amount of files can be stored on a Linux/Unix OS, but a large amount of files in a single directory inevitably slows down the filesystem search. Although rare, it is a problem.
To tackle this issue, the option of modifying the storage path through the project's settings could be added to the library. The current setup would remain the default option (e.g. daguerre/2016/10/12/), but the developers working on the project could opt for a more customized path. For instance, they could use hash subdirectories for saving image variations (e.g. /daguerre/ha/sh/dr/). A working example is already implemented in our fork.
What are your thoughts on the matter? I'd be happy to implement it and send you a pull request.