Massive - no way to create general purpose commands for Execute(DbCommand)
mikebeaton opened this issue · comments
Massive.Shared.cs has public methods to execute a single command public virtual int Execute(DbCommand command) or a collection of commands public virtual int Execute(IEnumerable<DbCommand> commands).
However, there is no public way to create a correctly formed, general purpose Massive command, i.e. one created using var result = _factory.CreateCommand(); and then SetCommandSpecificProperties(result);, as currently done in private DbCommand CreateCommand(string sql, DbConnection conn, params object[] args);.
Because of the way Massive handles connections (in almost all cases creating them itself to execute what is passed in) it does not seem correct to just make private DbCommand CreateCommand(string sql, DbConnection conn, params object[] args); public, but it does seem to make good sense to provide a new public alias private DbCommand CreateCommand(string sql, params object[] args)?
Note that while the same functionality is already covered for a single command by public virtual int Execute(string sql, params object[] args) this still does not address the issue of not being able to create correct commands to pass to the other two variants of Execute, especially the multiple command variant.
Apologies, I see that Massive supports CreateDeleteCommand, CreateInsertCommand, CreateUpdateCommand and CreateUpdateWhereCommand. So my original (pre-edited) point is incorrect, and the public Execute methods can certainly be used.
But it still seems it might make sense to also provide public access to a general purpose CreateCommand, as I suggested? (For instance, even in current Massive, this could be used to make a simple stored procedure command, to be executed along with other commands.)
But it still seems it might make sense to also provide access to a general purpose CreateCommand, as I suggested? (For instance, even in current Massive, this could be used to make a simple stored procedure command, to be executed along with other commands.)
In general it helps if you have a concrete use case, i.e. you want to do things in way ABC and it can't be done unless feature X is added, which justifies the addition of X. It might very well be to do ABC, not X should be added but Y. (not that CreateCommand shouldn't be added, but there has to be a use case for it, for which it is the best option)
I agree that I do not have a concrete use case, just a general idea that if Massive already has a public way to accept and execute a sequence of Massive commands, then it makes sense to provide the user with the full flexibility to generate those commands.
If the user did currently want to execute a sequence of commands which included something which the four currently public CreateXXX methods do not support (e.g. an SP call) then it would look very tempting to pass in a DbCommand which they had created themselves (i.e. not via Massive) as part of their IEnumerable list - but this would be potentially incorrect since a user generated DbCommand is not correctly initialised.