Hi,
It would be nice if you support SQL Server FILESTREAM and FileTables in EF Core.
MarcoLoetscher
All 10 comments
How would that be different than the current support for varbinary(max) ?
ErikEJ
on 16 Feb 2016
For FILESTREAM, it should use the class SqlFileStream because this class use the Win32 streaming support (OpenSqlFilestream API) File System Streaming Access.
FileTable Schema has two columns (path_locator and parent_path_locator) of datatype hierarchyid. It should be possible to map this table with a POCO.
MarcoLoetscher
on 16 Feb 2016
I think it is more accurate to say that it would be beneficial to have streaming access support for FILESTREAM. This is what the Win32 streaming support is specifically for. Otherwise you can pull data from a FILESTREAM object as a varbinary(MAX) as @ErikEJ mentioned. The streaming is not that good depending on the size of the object...but hey, ya do what you have to do.
The more problematic aspect if you want to support it is how do you make this consistent with the rest of EF experience which is traditionally a two-way street. Meaning that you could theoretically easily map an existing FILESTREAM field but how would you be able to effectively create a new table with a FILESTREAM column via migrations? There are sticky prereqs that come with it ....
How do you enable FILESTREAM if it is not enabled already(it is an instance wide setting) ?
How do you enforce the NON NULL unique row id requirement?
How do you create the FILESTREAM filegroup?
There are a couple of very manual ways that you can get around this currently in EF 6. However, they don't address the fact that you need to have a FILESTREAM enabled instance which requires you to change configuration and have specific objects set up within the target database to hold the FILESTREAM data.
With that said, I would also advise that the FILETABLE support be split out into a separate issue, because although it piggybacks somewhat on the FILESTREAM architecture, it is inherently different and comes with it's own unique set of "features".
So while I would openly support such a set of features, I would be estatic just to have a one way method of streaming the data using the Win32 processes through a property on a POCO.
ArieJones
on 17 Feb 2016
Agreed with previous comments that FileTable is a distinct feature in SQL Server that would require extra work to support. I won't create a separate issue right now but we can do it when get to implement FILESTREAM support.
Also, keeping this issue to track specifically adding support for FILESTREAM column mapping in our metadata, migrations and reverse engineering pipelines when using SQL Server. Mapping large binary columns to stream properties is tracked separately in #6234.
divega
on 9 Aug 2016
Hi, is there any workarround for the missing SqlFileStream in windows?
sepplK
on 21 Jul 2017
As I understand FILESTREAM support is missing due to the absence of SqlFileStream support in SqlClient on .NET Core.
See dotnet/corefx#15652
evil-shrike
on 22 Aug 2017
Is there any work around with regards to this I see that you can't even access the API through .net standard.
HashSix
on 4 Apr 2018
Seems like the API relating to direct access to filestream files is closely coupled with the Win32 API, being based on OS file handles and such. A workaround if you know you are targeting a Windows platform might be to use the System.Sql.Data from the .NET Framework, i.e. the non .net standard assembly that has the SqlFileStream class in it, with DllImports (or whatever) onto the Windows API.
Otherwise, from a Microsoft point of view, maybe an alternative API could be provided based on managed classes such as FileStream.
colgreen
on 4 Apr 2018
Any news on this?
pantonis
on 24 Jan 2020
@pantonis This issue is in the Backlog milestone. This means that it is not planned for the next release (EF Core 5.0). We will re-assess the backlog following the this release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.
ajcvickers
on 24 Jan 2020
Related issues
iberodev
路
3Comments
miguelhrocha
路
3Comments
TPJ11
路
3Comments
HappyNomad
路
3Comments
HeMinzhang
路
3Comments
Most helpful comment
I think it is more accurate to say that it would be beneficial to have streaming access support for FILESTREAM. This is what the Win32 streaming support is specifically for. Otherwise you can pull data from a FILESTREAM object as a varbinary(MAX) as @ErikEJ mentioned. The streaming is not that good depending on the size of the object...but hey, ya do what you have to do.
The more problematic aspect if you want to support it is how do you make this consistent with the rest of EF experience which is traditionally a two-way street. Meaning that you could theoretically easily map an existing FILESTREAM field but how would you be able to effectively create a new table with a FILESTREAM column via migrations? There are sticky prereqs that come with it ....
How do you enable FILESTREAM if it is not enabled already(it is an instance wide setting) ?
How do you enforce the NON NULL unique row id requirement?
How do you create the FILESTREAM filegroup?
There are a couple of very manual ways that you can get around this currently in EF 6. However, they don't address the fact that you need to have a FILESTREAM enabled instance which requires you to change configuration and have specific objects set up within the target database to hold the FILESTREAM data.
With that said, I would also advise that the FILETABLE support be split out into a separate issue, because although it piggybacks somewhat on the FILESTREAM architecture, it is inherently different and comes with it's own unique set of "features".
So while I would openly support such a set of features, I would be estatic just to have a one way method of streaming the data using the Win32 processes through a property on a POCO.