You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is absolutely brilliant... ability to execute SQL outside DB engine is just what is needed to migrate monolithic/legacy SQL/Store Procs based system bit-by-bit into more modern era, running on CLR...
One question... is the query expression tree build from SQL able to run against IQueryable "data source" ("SQL Table" being IQueryable object)?
The text was updated successfully, but these errors were encountered:
That's a great suggestion, actually. When I wrote NQuery originally, VS 2005 was the new hotness, so IQueryable<T> wasn't a thing yet :-)
What are you hoping to get out of it? NQuery will be able to read anything that is based around IEnumerable<T>; I assume you'd like the ability to generate actual SQL to query a real DB?
Would like to break large monolithic SQL code base into smaller pieces... and migrated into C# solution (bit-by-bit); however, can't rewrite all at once... hence... some parts of queries would remain in SQL (language), those queries would return IQueryable (say via NQuery); then C# could take over; add migrated/additional query logic (via LINQ)... and then, at the end, evaluate final IQueryable (via Entity Framework)...
Production of Expression Tree nodes that work with IQueryable (EF) is ideal outcome (and one that would require significant effort, come to think of it); however, may get mileage of IEnumerable too, in my scenario.
This is absolutely brilliant... ability to execute SQL outside DB engine is just what is needed to migrate monolithic/legacy SQL/Store Procs based system bit-by-bit into more modern era, running on CLR...
One question... is the query expression tree build from SQL able to run against IQueryable "data source" ("SQL Table" being IQueryable object)?
The text was updated successfully, but these errors were encountered: