Love it!!

[weedkiller]

This is like blue print for NqSql and JS, but only better!

Can you also support graphs like stateless - and markdown. With this you can easily do graph or db queries - i.e. go back and forth without worrying what the backend is, for e.g. I could tell it query a queue or even stream or db or graph!!!

Way to go FANTASTIC job 🏆

[VitaliyMF]

@weedkiller not sure that I understand you question (or feature/example suggestion?). Could you provide a bit more information?

[weedkiller]

I was saying this is similar to or between ~Blueprint & ~linq on the JS data schema side (look it up). Beyond that, as I see it - you're providing database independence.

So I was saying if you could let the developers treat any data source and query it as a db it would be helpful.

Right now, a developer needs to implement separate ESB vs SSO vs workflow vs streams vs queues, vs db, while in fact they all are inherent data sources, albeit with diff structures. The difference is querying something from a different source based on a different structure.

Going back to what your aim is - container independence enablement, I think this fits nicely.

abstract db-agnostic Query structure (no need to compose SQL)... provider-independent DAL

[VitaliyMF]

@weedkiller well primary goal of NReco.Data is to offer ADO.NET provider-independent API for querying tabular data (SQL by default, but connectors to NoSQL data sources - like MongoDb - could be easily added). Unlike EF, this library is friendly for dynamic queries and schema-less data access style (in other words, you don't need to define POCO model for every result type).

If you want to use Query class (and, possibly, 'relex' syntax and parser for it) for querying (or filtering) objects you can implement an engine that processes Query structure as you need. For .NET object lists/streams it is possible to have a generic implementation (do you need it?).

[VitaliyMF]

I guess this question is no longer actual.