Oren,

eSQL gives you runtime ability to run queries against your objects.

You might suggest that LINQ does the same, but not really. eSQL gives you the ability to truly bring set based theory into higher level programming languages. There is a query optimizer built into the eSQL framework, so the queries on your object model take advantage of db concepts.

This is something current ORMs cannot do.

Secondly, I am pretty firm on my LINQ to SQL views - I am pretty sure of that.

SM

I also don't agree with the point that linq to sql is useless. It's not a powerful API, but that wasnt their goal either. Linq to sql is a simple persistence framework, it brings no real entity management to the table, which is precisely the area where the biggest usability points are gained for using a o/r mapper framework.

With eSql, I have to see what it turns out into... I think eSql is only useful inside an RDBMS, so as a replacement for T-Sql. However, often I simply don't understand all the new keyword definitions while one also could have picked T-SQL and minimally add a few keywords if there is too much ambiguity.

The problem I have with eSql is that it doesn't really solve a problem, it simply moves it around to a different level: querying isn't going to be easier, it's just a little different due to the syntactical differences.

@ Sahil,

There is a query optimizer built into the eSQL framework, so the queries on your object model take advantage of db concepts.

Can you explain that one again?

I don't think that eSQL does much in memory, it sends it to the DB for processing the query.

Do you mean that it can optimize the query itself before sending it to the DB?

That seems like a dangerous thing, since it can't know about a lot of the stuff that the DB knows when it does optimizations.

How is eSQL diferent from HQL? In fact, given that Hibernate's been around for years and runs against many databases, it seems like a pretty safe bet that eSQL will by necessity be a pale copy of HQL that talored to SQL Server.

ScalarQuery query = new ScalarQuery(

             typeof(UseInfo),


      "select sum(f.Num * f.Run) from UseInfo f where f.ProductSystem.Model=?  and f.StartTime>=? and f.EndTime<=? ", curSystem.Model, startTime, endTime


            );


       dd = (double)Castle.ActiveRecord.ActiveRecordMediator.ExecuteQuery(query);

       return dd;

I to say that I see LINQ to SQL as a pretty good ORM. If you use something like ObjectSpaces today LINQ to SQL's DataContext gives you much of that functionality tomorrow. If you are using NHibernate, they you will need to take a view on whether you need some of the features that are missing in LINQ to SQL - for example support for different DB vendors, concrete class inheritance mapping, association table mapping etc. I've made the case that LINQ To SQL could support many of those ideas, if there was a will.

I think there are a lot of myths around LINQ to SQL floating around out there; the idea that it is a prototying toy is one of them. Sadly I think its another case of condemnation by people who have not really examined its feature set and understood its purpose, because a lot of the disrepsect seems to be based on half-truths. Ted Neward needs to learn more as does Sahil.

And right now if you want to do PI, LINQ To SQL gives you a pretty good shot: http://iancooper.spaces.live.com/blog/cns!844BD2811F9ABE9C!397.entry and LINQ to Entities doesn't.

Frans -

When you say

"I also don't agree with the point that linq to sql is useless. It's not a powerful API, but that wasnt their goal either. Linq to sql is a simple persistence framework, it brings no real entity management to the table, which is precisely the area where the biggest usability points are gained for using a o/r mapper framework."

I think I echoed exactly that in my blogpost :-).

SM