You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Plz note I have not used ILS extensively, but evaluating it and below is an issue I came across.
When an EItem file is uploaded, it seems to be saved into the ILS db/system properly whereby it is attached to the Document and am able to download it again. But if I reboot the device, the file is gone leaving a ghost link to the file in ILS. I imagine it is because the /tmp directory got cleared after the reboot and the uploaded file was prolly stored in the /tmp filesystem. Or it may be due to some similar short lived storage, but the bottomline is the uploaded files are not persisting in the DB.
Steps to Reproduce
You can upload any file for a Document EItem from the frontend React app and can check it.
The setup is local with Docker services running both server and web client on Mac
Expected behavior
It seems like the initial problem is the persistence of these files. From what I can tell, the uploaded file is stored in the backend file system. Maybe it is designed to be persistent by mapping the file system into the server Docker container (but not being done when running non-containarized server locally). But regardless, the pointers to these buckets are stored in Postgres and the files being outside of it, the referential integrity is broken. Ideally, the files should be uploaded into/within Postgres itself (as BLOB or equivalent) instead of into the file system and that should solve the reboot persistence issue. There are many more reasons to have all the data (including files) reside inside the database without external references such as security, compliance, data isolation, backup & replication, etc.
Screenshots (if applicable)
Additional context
I am not too familiar with ILS, but testing it now again for potential use by a large client. You may plz correct me if any of the above observations/understanding is not right or there are other/better ways to realize above outcome. But it sounds to me like an important and required fix. Plz advise.
Thanks, Tim
The text was updated successfully, but these errors were encountered:
Package version (if known): Any recent version
Describe the bug
Plz note I have not used ILS extensively, but evaluating it and below is an issue I came across.
When an EItem file is uploaded, it seems to be saved into the ILS db/system properly whereby it is attached to the Document and am able to download it again. But if I reboot the device, the file is gone leaving a ghost link to the file in ILS. I imagine it is because the /tmp directory got cleared after the reboot and the uploaded file was prolly stored in the /tmp filesystem. Or it may be due to some similar short lived storage, but the bottomline is the uploaded files are not persisting in the DB.
Steps to Reproduce
You can upload any file for a Document EItem from the frontend React app and can check it.
The setup is local with Docker services running both server and web client on Mac
Expected behavior
It seems like the initial problem is the persistence of these files. From what I can tell, the uploaded file is stored in the backend file system. Maybe it is designed to be persistent by mapping the file system into the server Docker container (but not being done when running non-containarized server locally). But regardless, the pointers to these buckets are stored in Postgres and the files being outside of it, the referential integrity is broken. Ideally, the files should be uploaded into/within Postgres itself (as BLOB or equivalent) instead of into the file system and that should solve the reboot persistence issue. There are many more reasons to have all the data (including files) reside inside the database without external references such as security, compliance, data isolation, backup & replication, etc.
Screenshots (if applicable)
Additional context
I am not too familiar with ILS, but testing it now again for potential use by a large client. You may plz correct me if any of the above observations/understanding is not right or there are other/better ways to realize above outcome. But it sounds to me like an important and required fix. Plz advise.
Thanks, Tim
The text was updated successfully, but these errors were encountered: