Currently our ADO.NET providers receive a file path within its connection string to load a file from disk. A consumer request has been that we support the option to avoid the file system and use a Stream to pull in the persisted store of data. Their specific use case, is that they have an IFormFile instance of CSV data that was POST'd into them via a REST call into their application.
Therefore, the purpose of this task is to investigate a means which will avoid the file system. Should an abstraction be made which is a representation of the persistence layer? Will we offer a set of interfaces that they can implement to provide their own persistence solution? Or will this solution be limited in scope, customed for their direct application?
Note: A full solution would need to support both styles of persistence which we call FolderAsDB and FileAsDB. As it applies to this consumer request, since our CSV file format can't contain multiple 'tables' of data, then the solution would need to support FolderAsDB in order to accommodate them. In essense, a full solution then gives our providers an option of an in-memory database solution (like the ADO.NET SQLite Provider offers through its connection string). Although, SQLite's solution is to provide this alternative "persistence" layer themselves.
Follow up: Depending on the final determined outcome of this work, evaluate if it can be applied to extend our EF Core Providers (which use our ADO.NET Providers) to also support this feature.
Currently our ADO.NET providers receive a file path within its connection string to load a file from disk. A consumer request has been that we support the option to avoid the file system and use a Stream to pull in the persisted store of data. Their specific use case, is that they have an IFormFile instance of CSV data that was POST'd into them via a REST call into their application.
Therefore, the purpose of this task is to investigate a means which will avoid the file system. Should an abstraction be made which is a representation of the persistence layer? Will we offer a set of interfaces that they can implement to provide their own persistence solution? Or will this solution be limited in scope, customed for their direct application?
Note: A full solution would need to support both styles of persistence which we call FolderAsDB and FileAsDB. As it applies to this consumer request, since our CSV file format can't contain multiple 'tables' of data, then the solution would need to support FolderAsDB in order to accommodate them. In essense, a full solution then gives our providers an option of an in-memory database solution (like the ADO.NET SQLite Provider offers through its connection string). Although, SQLite's solution is to provide this alternative "persistence" layer themselves.
Follow up: Depending on the final determined outcome of this work, evaluate if it can be applied to extend our EF Core Providers (which use our ADO.NET Providers) to also support this feature.