whiteknight / castiron Goto Github PK

In BestMatchConstructorFinder we should improve the matching algorithm by checking and ranking compatibility. exact type match should lead to a better score than a type match which involves boxing/unboxing, casting or conversion.

Get the MySql adaptor working and tested

We should be able to do basic constructor parameter matching by position instead of by name

the IDbCommand.Prepare() method should allow fast reuse of a single command with multiple parameter sets. See about adding this kind of functionality to SqlRunner and maybe SqlBatch, so we can pass in a single query to .Prepare() and multiple parameter set objects for each invocation.

MapCompileOperation is a mess, and it delegates to ObjectCreatePreferences which isn't used appropriately. MapBuilder/IMapCompilerSettings also only exposes options for a single data type, when we potentially want to configure constructor/factory settings for all data types used throughout the graph.

The IMapCompilerSettings interface needs to be redesigned, possibly with changes to the IDataResults interface to support a more flexible configuration system.

Basically, we want to build a config tree where Types[]->subtypes[]->options. Then we can include this whole thing in MapCompileOperation and cache/retrieve constructor/factory information for each type as it's encountered.

StoredProc method would allow specifying proc name and parameter names, and create an ISqlQuery with type=StoredProc and the parameters setup.

In several of the mappers we have a TODO note like "TODO: This Substring is going to fail if we are more than 2 levels deep". First add tests to show that this is a problem, and then implement a fix.

See if we support this already, add tests

See if we can at least add a nice layer around it so we can pass in a list of objects and convert to a DataTable.

CastIron.Sql should be provider agnostic. MsSql code should go into a new CastIron.SqlServer instead

We want to be able to inspect the actual generated SQL code so if there's some kind of error we can figure it out better.

Would like to add a static SqlCommand class with factory methods, similar to the SqlQuery class which creates queries, or the Materializer class which creates Materializers.

As part of the MapCompiler and CompileSettings refactors, the old caching mechanism had to be removed. A new caching mechanism must be provided because map compilation to too expensive to do repeatedly for the same query.

The SqlQuery class which contains several factory methods for different ISqlQuery variants should expose the setup callback in more methods, and make sure those settings are passed down into the materializers

Currently we only support Tuple, but we should also support ValueTuple

We want to support ISet<T>, HashSet<T> and OrderedHashSet<T>

Add .Query method variants to take a Func<IDataInteraction,bool> callback, with and without a materializer, so we can do single-line queries with parameters.

Add an ARCHITECTURE.md file to the repo, explaining how the library is designed.

SqlRunner currently manages the lifetime of the connection end-to-end, so the result stream is closed when the method returns. We should have the ability to return an object representing an open stream, which can be read in a streaming fashion and disposed when completed.

StoredProc method would allow specifying proc name and parameter names, and create an ISqlQuery with type=StoredProc and the parameters setup.

.FromString should provide options to setup parameters with ISqlParameterized

We should be able to configure mappings at the runner level, or at the level of the runner factory, and not maintain a static source of mapping information. We can merge MapCompilation into SqlRunner or ExecutionContext as required.

In IDataResultsBase.AsEnumerableNextSeveral, it's possible that we are enumerating through multiple result sets, during which time another .AsEnumerable() call could be made. We should find a way to try and lock the result set so new concurrent reads cannot be started while existing reads are ongoing (we probably also want to do this for several other methods as well)

Make sure to keep track of state in the DataRecordMappingEnumerable (and variants), so that if the underlying reader has advanced to the next result set, we cannot continue to consume the enumerable for the previous result set.

We can't currently loop in the ArrayCompiler because (1) we don't know how many columns the custom object compiler is going to consume and (2) we need to set the length of the array up front. Instead we should change this to loop over a List instead of T[1], add items so long as we can continue to do so meaningfully, and then call .ToArray() on the result list. We lose a bit of performance but gain a lot more power in exchange.

Like we do mapping to constructor parameters elsewhere, in ParameterCache we should be able to map output parameters to constructor arguments, and then assign the remainder to public writeable properties.

We can use the connection string as a cache key to keep track of IDbConnectionFactory instances if necessary. If this is worthwhile, do it for all RunnerFactories.