nice and settled with the current version. are you at liberty to outline what coming in the verson 3.0?

cheers,

pete

I can't go into detail about a lot of things in v3, but it will be a reworked system: the designer will be partly rewritten, the system will be model first supporting and everything will be powered by a DSL (text), so you will be able to formulate everything in a powerful DSL (entity definitions, mappings, meta data etc.) which can be used to generate DDL SQL, classes etc. We'll also support other platforms beside our own o/r library.

We don't have an estimate release date, but we don't expect it to release it before the summer 2008.

In the mean time, we'll have 2.6, which we hope to have in beta before the end of the year, with Linq support, vs.net 2008 support, .net 3.5 support, some fixes with breaking changes. After that we'll likely release our DSL, with a conversion tool from/to .lgp projects, to try out what is good and what's bad in our DSL.

Between the your planned updates and MS MVC implementation, its gonna be a damn good time to be an asp.net developer. It's been a long wait. (MS Fault not yours at all!)

Pete

Otis wrote:

I can't go into detail about a lot of things in v3, but it will be a reworked system: the designer will be partly rewritten, the system will be model first supporting and everything will be powered by a DSL (text), so you will be able to formulate everything in a powerful DSL (entity definitions, mappings, meta data etc.) which can be used to generate DDL SQL, classes etc. We'll also support other platforms beside our own o/r library.

We don't have an estimate release date, but we don't expect it to release it before the summer 2008.

In the mean time, we'll have 2.6, which we hope to have in beta before the end of the year, with Linq support, vs.net 2008 support, .net 3.5 support, some fixes with breaking changes. After that we'll likely release our DSL, with a conversion tool from/to .lgp projects, to try out what is good and what's bad in our DSL.

I'm sure I don't speak for everyone, but with your excellent query support that is already 100% compile time checked, why waste your time with LINQ support? It seems like alot of work for very little gain.

Now, 3.0 sounds great!

BOb

I'm sure I don't speak for everyone, but with your excellent query support that is already 100% compile time checked, why waste your time with LINQ support? It seems like alot of work for very little gain.

Now, 3.0 sounds great!

LINQ is going to be massively used in near future - it will be everywhere, everybody will have to learn it sooner or later, so why don't support it? Not to mention that one can combine queries to different targets. Besides, did you ever write a real query, one that spans >10 tables? It becomes very unreadable and messy (because of current language limitations). LINQ should make it much more elegant and readable.

I am really looking forward to LINQ support mostly for the later reason.

PilotBob wrote:

Otis wrote:

I can't go into detail about a lot of things in v3, but it will be a reworked system: the designer will be partly rewritten, the system will be model first supporting and everything will be powered by a DSL (text), so you will be able to formulate everything in a powerful DSL (entity definitions, mappings, meta data etc.) which can be used to generate DDL SQL, classes etc. We'll also support other platforms beside our own o/r library.

We don't have an estimate release date, but we don't expect it to release it before the summer 2008.

In the mean time, we'll have 2.6, which we hope to have in beta before the end of the year, with Linq support, vs.net 2008 support, .net 3.5 support, some fixes with breaking changes. After that we'll likely release our DSL, with a conversion tool from/to .lgp projects, to try out what is good and what's bad in our DSL.

I'm sure I don't speak for everyone, but with your excellent query support that is already 100% compile time checked, why waste your time with LINQ support? It seems like alot of work for very little gain.

I agree, but marketing wise, it will be a big step so that's why we'll add it: people will know Linq syntaxis and it will be an alternative for people who find predicates etc. hard to grasp. On the other hand: we'll keep our own query system as it's more powerful than Linq so you'll have an alternative.

Linq has its own share of problems which will cause headaches for people: joins with compound keys, left/right joins, not knowing what the exact sql will be like etc.

These aren't easy problems, a lot of people will suffer from these, therefore I don't agree with the people who say it's always easier. Sure simple queries are perhaps a little easier, but simple queries were never a problem: the problems arise when complex queries are required, and then it gets tough.

So it's a trade off: some things gets simpler and you get an alternative querying system. I don't like how Linq works internally, and I think others will agree with that, and for these people we'll keep our own querying system and we'll keep on extending that in the future if necessary (in 2.6 we'll introduce derived table support for example, which was required for linq anyway).

One big thing which will hit a lot of people in the face is the lack of predictable SQL outcome. For applications which run on big databases, it's required that the developer can control what the SQL looks like in terms of: use joins or use subqueries etc. With Linq that's abstracted away, which means that if e.g. a DBA says to a developer: "Your code generates joins, could you turn that into a subquery instead? ", the developer has to give up, because the developer won't be able to do that with linq. With our own system of course s/he can

Now, 3.0 sounds great!

Thanks I'm very excited about the planned changes, and I'm sure it will bring us the platform for the coming years

mihies wrote:

I'm sure I don't speak for everyone, but with your excellent query support that is already 100% compile time checked, why waste your time with LINQ support? It seems like alot of work for very little gain.

Now, 3.0 sounds great!

LINQ is going to be massively used in near future - it will be everywhere, everybody will have to learn it sooner or later, so why don't support it? Not to mention that one can combine queries to different targets.

I'm not sure what you had in mind with that last sentence, but I don't see how you can combine queries to different targets if the IQueryable object itself contains a single target definition.

Besides, did you ever write a real query, one that spans >10 tables? It becomes very unreadable and messy (because of current language limitations). LINQ should make it much more elegant and readable.

We do what we can to make it a pleasant experience (did I just said 'experience'? aaaarggg ), like adding extension methods to define prefetch paths directly on the query, but don't get your hopes up too high that everything becomes easier.

For example, write out a left join using query which fetches all employees from northwind who don't have an order filed yet. That looks something like (I might miss a bit of syntax here and there, as I can't peek into the code right now as it's on my other dev box)

var q = from e in nw.Employee
    join o in nw.Order on e.EmployeeId equals o.EmployeeId into eo
    from x in eo.DefaultIfEmpty()
    where x == null
    select e;

I also wrote one with let, which accomplishes the same thing. I'm tired of asking MS why this horrible syntaxis made it into the final language def, so I don't know why they didn't opt for a 'left' keyword, but it would have been much better.

I'm not sure what you had in mind with that last sentence, but I don't see how you can combine queries to different targets if the IQueryable object itself contains a single target definition.

I did mean something like this:

var q2 = from x in (from c in db.Customers select c).ToArray() select new { x.Phone }; 

Silly example but it should demonstrate what I had in mind: you can LINQ over different worlds using same syntax.

We do what we can to make it a pleasant experience (did I just said 'experience'? aaaarggg ), like adding extension methods to define prefetch paths directly on the query, but don't get your hopes up too high that everything becomes easier.

I am fully aware of both, the fact above and your "battle" with MS However I think that combining LINQ with your effort should provide much better experience in general

mihies wrote:

I'm not sure what you had in mind with that last sentence, but I don't see how you can combine queries to different targets if the IQueryable object itself contains a single target definition.

I did mean something like this:

var q2 = from x in (from c in db.Customers select c).ToArray() select new { x.Phone }; 

Silly example but it should demonstrate what I had in mind: you can LINQ over different worlds using same syntax.

Ah yes, that indeed is possible. It can also open a pitfall though for people with lazy-loading enabled code in some areas, but then again, it's not my fault the language is designed like that

We do what we can to make it a pleasant experience (did I just said 'experience'? aaaarggg ), like adding extension methods to define prefetch paths directly on the query, but don't get your hopes up too high that everything becomes easier.

I am fully aware of both, the fact above and your "battle" with MS However I think that combining LINQ with your effort should provide much better experience in general

True, I think the aspect of linq being a general part of vb.net/c# so people get it taught in courses and via books is a plus, people will already know specifics of the language before using LLBLGen Pro.

There are things we won't support however. Currently I've scratched 'Skip' off the list and have introduced 'TakePage()' instead, as our API doesn't use skip/take, it uses pagenumber/size. With Skip, people could specify a number to skip which isn't a multiply of the page size. I'm thinking perhaps with a hacky way it is supportable (specifying the skip parameter as the pagesize, set pagenumber to 0 and set MaxNumberOfElementsToReturn to the # of elements to return (the take), but it's fishy...

Frans, you will never get a job at Microsoft unless you learn the correct terminology. I think you have to provide a "rich user experience." If you say it 100 times a day you may soon come to believe it.

Midnight wrote:

Frans, you will never get a job at Microsoft unless you learn the correct terminology. I think you have to provide a "rich user experience." If you say it 100 times a day you may soon come to believe it.

I always get a little bit of stomach ache when I say 'experience' 10 times in a row

I think that linq makes little sense as an extension to the language. Ok sorry, I'm off

stefcl wrote:

I think that linq makes little sense as an extension to the language. Ok sorry, I'm off

Shees, that was a deep thought I think 99% of developers wouldn't agree.

I don't mean that linq is a bad thing, I just don't understand why it has to be an extension of a programming language like C#. Perhaps you'll agree that Linq is like a DSL in many ways... I hoped they would have enhanced C# or VB.net so that they could support DSLs in a more general manner, allowing people to write their own.

stefcl wrote:

I don't mean that linq is a bad thing, I just don't understand why it has to be an extension of a programming language like C#. Perhaps you'll agree that Linq is like a DSL in many ways... I hoped they would have enhanced C# or VB.net so that they could support DSLs in a more general manner, allowing people to write their own.

Exactly my thoughts.

Linq is now implemented in a bad way, everything had to sacrifice to make it work, which is a bad thing IMHO. they didn't look at what would help the language forward, but what made it possible to implement Linq (e.g. extension methods but not extension properties).

Expression trees are not consistent because Linq to Objects required that some constructs are combined while linq to objects doesn't even use expression trees. Example: from c in nw.Customers join o in nw.orders on c.CustomerID equals o.CustomerID select c; This query doesn't have a .Select() method call, the projection of select is combined with the projection in the Join. However: from c in nw.Customers join o in nw.orders on c.CustomerID equals o.CustomerID where o.EmployeeId ==2 select c; DOES have a .Select() method and the result projection of the join ISN'T the select. Stupid design.

But the worst is the language translation rules. This doesn't compile:

var q = from c in nw.Customers 
            join o in nw.orders on o.CustomerID equals c.CustomerID 
            select c;

but this does:

var q = from c in nw.Customers 
            join o in nw.orders on c.CustomerID equals o.CustomerID 
            select c;

The first doesn't compile because c and o aren't in scope.

Now, please explain to me why is this a step forward. The reason why this craps on you during compile time is because the join is translated to a .Join() extension method call and the first and second selector lambda will become: c=>o.CustomerID and o=>c.CustomerID which means of course that c and o aren't in scope. The second version has them in the right order. This conversion is done by the compiler, so it's out of sight for the developer, however the developer HAS TO KNOW these rules to be able to write compilable code.

For me, as an end user, LINQ is great as it will allow me to solve certain everyday problems efficiently and easily, it will improve the clarity of the code, provide unique query language over anything, etc. Now, one might want general DSL. What for? I mean, general developer doesn't need it. But if you need it you might turn to another language that supports it, why not? If something general would be allowed, C# would become a mess soon enough, wouldn't it? And while LINQ isn't perferct (it would be good if they listened to guys like Frans) and has some oddities it is still a great step forward.