-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Include the "save file" action (.ZIP file) as part of model.SaveFile() #1689
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
We already have |
Also, there are shorter ways to create a file stream: using (var fs = File.Create(ModelPath)) |
Important to note is that, as I mentioned, it should also have the possibility of using an existing file stream.
For instance, in the case of the XMLDocument, it provides 4 overloads, by using stream, just the filepath, TextWriter and XMLWriter: https://docs.microsoft.com/en-us/dotnet/api/system.xml.xmldocument.save?view=netframework-4.7.2 A few examples of .NET libraries where you just need to provide the file path name without having to deal with any stream: XML Document
WORD Automation in C#:
VS Document.Save(path) Method VS Graph Save(path) method In Python / Scikit-Learn you also use a single API step: dump
In contrast, we currently need to handle the FileStream object in between: This is what we have now:
or this
But the simplest step would be to just provide the filePath:
Btw, I guess we always need to provide the mlContext in order to save the model sa a file, right? In any case, this is a minor improvement/simplication, not a big deal, but since the implementation is simple, that's why I'm suggesting it. :) |
Can this also be made Async? |
Please ensure that for model saving and loading there exist both stream and string based overloads. |
Related #2983 |
Currently, whenever we are saving a .ZIP model file, you always need to handle the code for the File stream class.
I think that is repetitive code that could be included in the API.
Instead of:
We could have an overridden method so I could simply do the following:
mlContext.Model.Save(trainedModel, modelPath);
Or even the following, if those methods were part of the model class itself instead of a utility class in the MLContext:
model.Save(modelPath);
Currently, this kind of line using the file stream class is something you need to repeat over and over in every/most training app (even when the constructor can be simplified):
using (var fs = new FileStream(ModelPath, FileMode.Create, FileAccess.Write, FileShare.Write))
Handling a FileStream object might should not be mandatory for the user but optional:
Of course, I would also maintain the current methods because in some cases you might want to just provide an existing stream object, but as opt-in.
The text was updated successfully, but these errors were encountered: