querybuilder
querybuilder copied to clipboard
sqlkata
Several micro improvements
- Micro Improvement - Compiler.Wrap
BenchmarkDotNet=v0.12.0, OS=Windows 10.0.18362 Intel Core i7-7820HQ CPU 2.90GHz (Kaby Lake), 1 CPU, 8 logical and 4 physical cores .NET Core SDK=3.0.100 [Host] : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT DefaultJob : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT
| Method | Mean | Error | StdDev | Ratio | Gen 0 | Gen 1 | Gen 2 | Allocated |
|---|---|---|---|---|---|---|---|---|
| Unmodified | 492.4 ns | 9.87 ns | 17.29 ns | 1.00 | 0.0896 | - | - | 376 B |
| Modified | 281.8 ns | 3.46 ns | 3.23 ns | 0.57 | 0.0591 | - | - | 248 B |
- Replaced Query.Method string with enum QueryMethod
- Replaced AbstractClause.Component string with enum ClauseComponent
- Removed redundant 'object.ToString()' calls
- Fixed String.IndexOf with StringComparison.Ordinal
- Fixed Empty object or collection initializer list
- Fixed redundant string interpolation
- Fixed redundant emtpy statement
@ahmad-moussawi Could we get these reviewed before the base library moves too far away from the version these were implemented in?
@samtrion @b-twis my only concern in the PR, is that using enum instead of string for the component section will limit the ability to extend the query/compiler behavior in the future. The developer can build his extension methods to add custom components and override the compiler to digest these components, but when using enums, this will not be the case. of course I am open for discussion about this.
I understand your thoughts on expandability. However, since this is strongly based on SQL, there should be almost no potential for conflict with the existing syntax.