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
When developers use the file provider, they should understand these limitations, such as the difference between the file system in Linux and Windows, the special characters allowed in the file name, the maximum length of the path, etc. Azure provider is the same.
We should not normalize it, and normalization should be a process that is not perceptible to developers. Just like BlobStoring supports multi-tenancy.
@hikalkan If you think this is necessary, I can implement the above function.
I partially agree. Yes, if developer knows the underlying storage provider, she/he is responsible to follow the rules, no problem about that.
The problem is when we are developing a reusable module and can not know the provider that will be used. Our module should be compatible to all providers, right? What if someone creates another provider that we don't know and this provider has another naming limitation. How can we name objects that fits to all possible providers? It is best the provider intergration package knows the limitation and adapt (tolerate) it if possible.
I have some ideas about whether it is allowed to register and use multiple storage providers in the same file service at the same time. If different tenants may use different storage providers, I have designed a file table, which identifies which storage provider this file uses. When the file need download, I can get the blob container of the corresponding storage provider through this identifier in the file table. At present, only one provider type can be set for containers. Can we provide an AddProvider() function for TypedList? What do you think? Some code example of AspnetBoilerplate version :
@maliming what do you think?
The text was updated successfully, but these errors were encountered: