Support for direct queries without using the LINQ api

[borigas]

Provides a workaround for query edge cases that aren't supported

[matteobortolazzo]

Good idea!
Also query from string.
And the README must be updated.

What is not supported at the moment?

[borigas]

Query from string was my 1st goal too. I think this does support string though. Flurl will take whatever object you pass and JSON serialize it to send. If it's a string, it'll serialize to itself.

I'm not currently aware of anything not supported, but I wanted a workaround available if I found something else like the Guid .In() change from #31 so I wasn't blocked until it got merged

[matteobortolazzo]

If you serialize a string it will wrap everything in "".
For example "{"selector":{"name":"Luke"}}" and it's not a valid JSON.

No worries, I'm working on this.

       public Task<List<TSource>> QueryAsync(string mangoQueryJson)
        {
            return SendQueryAsync(r => r
                .WithHeader("Content-Type", "application/json")
                .PostStringAsync(mangoQueryJson));
        }

       
        public Task<List<TSource>> QueryAsync(object mangoQuery)
        {
            return SendQueryAsync(r => r
                .PostJsonAsync(mangoQuery));
        }

        private async Task<List<TSource>> SendQueryAsync(Func<IFlurlRequest, Task<HttpResponseMessage>> requestFunc)
        {
            var request = NewRequest()
                .AppendPathSegment("_find");

            var message = requestFunc(request);

            var findResult = await message
                .ReceiveJson<FindResult<TSource>>()
                .SendRequestAsync()
                .ConfigureAwait(false);

            return findResult.Docs.ToList();
        }

[borigas]

And that's why I should've written a test for both use cases... Good catch and thanks for fixing it

[matteobortolazzo]

No worries :)
1.0.1-beta.4 out soon