Repository navigation
Multiple manifests support per graphic folder - currently only one manifest is seen - #20
Jace-10110 wants to merge 1 commit into
Conversation
A folder MAY hold several manifest files. The specification is explicit that they
are then "interpreted as multiple, independent Graphics", and that this "can be
useful for example when having a package of multiple OGraf graphics, which then
might share resources such as images, fonts, etc."
findManifestFile() returned the first manifest file readdir() happened to yield,
which is not an answer to "which Graphic is in this folder". getGraphicInfo() then
did the right thing and rejected the folder, because the manifest it had been
handed declared a different id:
Folder name graphic-<a> does not match manifest id <b>
So of a package of three Graphics sharing one folder, exactly one loaded and the
other two returned 500 for every load. Which one worked depended on readdir order,
so it was not even stable between machines or filesystems.
findManifestFile() now takes the id the caller is asking for and returns the
manifest carrying it, falling back to the previous behaviour when the id is not
known or no manifest matches — the callers that check the id themselves are
unchanged. Both id-known call sites, getGraphicInfo() and getGraphicManifest(),
pass it. The legacy folder-rename scan has no id to match and keeps taking the
first manifest, which is correct for the single-manifest folders it deals with.
Verified against a storage root holding a three-manifest package: all three ids
now resolve to their own manifest and their own name, where previously only the
alphabetically-first one did.
(cherry picked from commit 40e1095)
|
There was actually a mechanism to handle this already in place, but when I looked into it it turns out that it didn't work properly. When uploading, a scan for all ograf-manifest files in the zip-file is done. Then a copy of the ograf-folder is made for each ograf manifest file. This way, the multiple-ografs-in-one are kept separate and allowed to be handled/listed/deleted independently. What didn't quite work however, is that an internal By having a fixed-name manifest file, there is no need for looking through several (potentially many) files for each graphics-listing. I've pushed a fix that should fix the issue here: a884689 , please test and let me know if it doesn't resolve your issue. |
A folder MAY hold several manifest files. The specification is explicit that they are then "interpreted as multiple, independent Graphics", and that this "can be useful for example when having a package of multiple OGraf graphics, which then might share resources such as images, fonts, etc."
findManifestFile() returned the first manifest file readdir() happened to yield, which is not an answer to "which Graphic is in this folder". getGraphicInfo() then did the right thing and rejected the folder, because the manifest it had been handed declared a different id:
So of a package of three Graphics sharing one folder, exactly one loaded and the other two returned 500 for every load. Which one worked depended on readdir order, so it was not even stable between machines or filesystems.
findManifestFile() now takes the id the caller is asking for and returns the manifest carrying it, falling back to the previous behaviour when the id is not known or no manifest matches — the callers that check the id themselves are unchanged. Both id-known call sites, getGraphicInfo() and getGraphicManifest(), pass it. The legacy folder-rename scan has no id to match and keeps taking the first manifest, which is correct for the single-manifest folders it deals with.
Verified against a storage root holding a three-manifest package: all three ids now resolve to their own manifest and their own name, where previously only the alphabetically-first one did.