Support IQueryable Interface

[mikependon]

No description provided.

[mikependon]

The expressions are now supported by RepoDb. The IQueryable will not be totally supported by now.
Deployed at version 1.7.0-beta3

[cajuncoding]

Hmmm, I'm not 100% sure on the conclusion here, but it looks like Expressions were implemented but IQueryable is not. Too bad, would be useful for integration with something like HotChocolate (GraphQL) without a dependency on EntityFramework....

[mikependon]

Thanks for commenting here. It was discussed through reddit TBH last 2018, and even Matt Warren of Microsoft tend to make a comment in relation to this, it was a bit heated topic. However, internally, we had decided to only support the IEnumerable and not the IQueryable.

There are various reason, one reason is to ensure that our solutions are still working when we are changing the Dapper with minimal code alteration. Secondly, IQueryable is a bit high-level when being compared to IEnumerable in which I think going through this path would completely invalidate the purpose of this ORM. We will not be competing with EF, in which it is very fully integrated to it, I would assume, people will just use EF right away (defaultly) over RepoDB in relation to IQueryable.

But it a sense of fully supporting it, it is still feasible via extension library in a sense of making the RepoDB the core executor on the deferred execution capability, however, we have not yet placed that on the pipelines.

[cajuncoding]

@mikependon thanks for responding!

Yes, to be honest, I agree! And yes, if IQueryable is needed then Entity Framework is the way to go.

I'm working with HotChocolate GraphQL on some projects, and it's current design is opinionated in that all of the advanced GraphQL features are done for you (Sorting, Paging, Filtering), but rely on IQueryable and integrates well with EF in that "black-box-of-magic sort of way".

But in real world applications I find EF to be a poor choice for variety of reasons. For example, with HotChocolate GraphQL then all the logic would be then tightly coupled and integrated inside of the EF + GraphQL internals, via IQueryable. Control is completely removed from developers.... which is great to get something working in 1 day, but has all sorts of implications from performance to teaching developers bad habits over the longer term.

This is something I really like about RepoDb, it brings to the table more power than Dapper, but no control is lost. I'm working on some things that will try to bring RepoDb together with HotChocolate GraphQL.... and will share something out once I've ironed some things out.

PS... thank you soo much for exposing the PropertyCache<> publically! That's saves alot of effort from creating custom Reflection for mapping GraphQL requests to RepoDb instructions... it's working well in my POC.

[mikependon]

Thanks man! Looking forward on the extension library you are creating. Glad if you/we could push that and we can make it as an official extension RepoDB library on HC's GraphQL.

thank you soo much for exposing the PropertyCache<>

Welcome! Btw, you can either use the FieldCache, DbCache and/or PropertyCache objects to reflect everything (just once) in the lifespan of the application domain.

P.S: If you could wait a little further, I am planning to create a DbTableCache object that reflects the DB's table, and that will be a part on the complete support of ExpandoObject on all push operations. It will be a part of the v1.12.5 (probably).

[cajuncoding]

Wow, thanks for the fast & detailed responses. It's most appreciated!

Yes, one of my goals is to definitely share out what I can for integrating HotChocolate & RepoDb. Or really for anyone looking to use a .Net stack with HotChocolate for GraphQL and a lighter weight, bare-metal Orm framework like RepoDb... which I'm enjoying working with more and more every day. And Sql Server.... as that's my DB of choice.

I hate to de-rail this github issue much more, but I have enjoyed the initial collaboration. And this integration has brought about a couple of interesting questions for RepoDb specifically.... For example, this weekend I finally got a full flow working for Paginated GraphQL via RepoDb and Sql Server.... the BatchQuery() API initially would have been perfect, however there is currently no overload that uses a true Cursor (e.g. Relay Spec for Cursor Pagination) -- and that was my design goal. So I implemented as a CustomExtension on the BaseRepository class as an initial POC and it's working well.

I'd like to collaborate with you a little more on the best way to extend RepoDb with this capability or even contribute to RepoDb something useful? Let me know if you would be interested.

Is there somewhere else you'd rather collaborate on? Maybe I should create a new Issue thread?

[mikependon]

however there is currently no overload that uses a true Cursor (e.g. Relay Spec for Cursor Pagination)

You might be looking on the SkipQuery API in which we are planning to implement soon. See #377

I'd like to collaborate with you a little more on the best way to extend RepoDb with this capability or even contribute to RepoDb something useful? Let me know if you would be interested.

Anytime and anything, actually.

RepoDB is also getting bigger in terms of covered use-cases, therefore it is also getting complicated to support. There are tremendous requests to support many things, but I am controlling such the framework to stay as small as possible and trying to eliminate requested features that I think would make RepoDB a competitor of big ORMs like EF, NH and LLBLGen.

The only intention of mine here is to provide a framework to the OSS community that could allow them to utilize and maximize the power of the underlying RDBMS, instead of the C# (or .NET Engine) itself, though, I as well doing my best to make RepoDB as performant and efficient as possible.

So, anything that you can contribute to the project is highly appreciated. It would be good if we can start to an extension library, specifically GraphQL and IQueryable integration.

Btw, most users of RepoDB are contacting me directly through GitterChat, you might as well can message there anytime.