Address Dictionary query generation

[baronfel]

Addresses #459

There are some dramatic changes in this.
Applying fixes for the IDictionary<,>.ContainsKey('tkey) and ICollection<KVP<,>>.Contains(KVP<,>) cases was easy enough because those fit into the existing method-call based plugin architecture. There was a wrinkle in that the operator that I want to use in postgres is ?, which is already used by the WhereFragment expansion, so I also took the opportunity to make a version of WhereFragment that has a configurable separator.

The drastic thing was adding in a pluggable IBinaryExpressionParser interface. This was required so that I could easily get at cases where we're indexing into a dictionary on the right or left sides to pull out the keys and values to construct the comparison dictionary. As you'd expect a ton of things broke right off the bat, so I spent some time tweaking the Matches condition on the SimplePropertyBinaryExpressionParser. Please please please please please please sanity check me on that. The tests pass on my local box now but there's no way they're exhaustive in this circumstance.

• Should we add a publicly-facing extension point for IBinaryExpressionParser instances like there are for IMethodCallParser instances?
• I'd also like to add some more tests actually storing and querying for data based on these dictionaries before I take the [WIP] off of this.
• Also, thoughts about generic dictionary access? I think it's safe to say that the most extreme we could go is IDictionary<string, TValue>, because json maps must have string keys, so is that worth going ahead and doing here?
• Also, I want to buff out the binary parsing some more to accept more than dict["key"] == "value".

[jeremydmiller]

Oh man, how upset w/ me would you be if I asked you to solve the "?" problem a different way? Leave "?" substitution the way that it was, and maybe use custom IWhereFragment's for the places where you need that operator? The question mark thing is a common usage and I'd prefer to keep it.

And would you also mind rebasing this on master?

[baronfel]

I'm actually in the middle of a rebase (kinda scary looking, with csproj changes :)

I could also do a custom WhereFragment, easy enough to revert that commit. No hurt feelings at all, that's why the [WIP]!

[jeremydmiller]

@baronfel Actually, @CoreyKaylor is in the process of removing all the csproj files and putting us squarely on project.json. You might have a better time waiting for that.

A way we could maybe do this is have the substitution wildcard not be hardcoded inside of WhereFragment. Keep "?" as the default, but let you override that on an individual WhereFragment?

[baronfel]

Sounds like I'll take a breather then and wait for the csproj churn to finish :D
I can do a separate PR for the configurable WhereFragment as a smaller chunk while I'm waiting for all that to settle.

[CoreyKaylor]

Already in master.

[baronfel]

Thanks, rebasing and making the WhereFragment configurable.

[baronfel]

needed this to make the tests green up on my machine

[CoreyKaylor]

Looks like quite a few failing tests on the build server for this branch.

http://build.fubu-project.org/viewLog.html?buildId=47864&tab=buildResultsDiv&buildTypeId=Marten_Master&guest=1

[baronfel]

Oh that's expected. I've been having trouble running all the tests successfully on my machine (my poor docker Postgres instance seems to be getting swamped), but I'm still in the process of cleaning things up on my end. I'll remove the [WIP] and ping you all when things are closer to done, I just wanted initial feedback and validation on the approach.

[CoreyKaylor]

Just making sure we weren't the ones dropping the ball on getting this taken in. 😄

[baronfel]

I'm going to reel this back a bit and skip doing the dict[key] == value pattern right now, because that's a TON of extra work around making sure that we flatten/resolve the left and/or right expressions correctly to try and pull the value out of them to construct the json dictionary. So just looking at the Contains(KVP) and ContainsKey(K) methods right now.

[baronfel]

Ok, I removed the [WIP] on this PR. We now handle ICollection<KeyValuePair<string,T>>.Contains(KeyValuePair<string,T>> and IDictionary<string,T>.ContainsKey(string) cases generically, and optionally have the ability to set the NpgsqlDbType on a sql parameter, which was necessary when using the @> operator to check for the presence of a key-value pair in a jsonb object. Separate PRs can address the dictionary index question, because that junk is HAIRY!

[CoreyKaylor]

Thanks