InfoQ Interview: Jimmy Nilsson on LINQ to SQL

It seems the comments of this article are lost.

Yes - I'm looking into what happened. It is my hope that we can recover the comments as we place a very high value upon them.

-james

Too bad. Thomas, if you're still listening, i'd still like to learn how you think you can use syntax like this:

where(equals(myAlias.myMemberVariable, whatever))

(from one of your test cases)

because I think without any quotation mechanism (which java does not have), you cannot.

The trick is to use Object identity. Let's say you have:
class Product { String name; }
Then when the product is initialized:
Product p = alias(Product.class);
a new String instance is assigned to p.name (new String()). Then when from(p) is called, p is added to the list of alias objects, and all it's members ('name'; using reflection) are added to a identity hash map. Then when you call equal(p.name, ...), the engine checks in the identity hash map what objects are passed. So you could even do this (not that you should):

Product p = alias(Product.class);
String pName = p.name;
from(p).where(equal(pName, "Jones")).select(pName);

Regards,
Thomas

Clever. So that's why your test domain classes use Integer and Double member variables instead of int and double - because they need identity for every single value, right? But this is hardly the case for real-world classes, is it?

Also, you'd have to do a very deep initialization to make queries like equal (p.Customer.Name) possible, which is rather unlikely.

You require a default constructor, which you actually call. Creating instances and setting their members to arbitrary values might have side effects though, especially in ORM situations that quaere is probably targeting (automatic enlistment in unit-of-work, range checking...).

So you need to make a lot of stuff in your apps and frameworks fit the quaere model, application developers need quite some knowledge so they can actually write working queries without trial-and-error, you have very limited compile-time support, and the syntax is quite hard to read compared to LINQ. I think you're not doing yourself a favor insisting that you provide 95% of LINQ.

But still, clever! I don't think you could go much further with Java.

In regard to the comparison between Hibernate and Linq, I believe that Jimmry neglected a major difference that differentiates Linq from all the other ORM frameworks which is Linq is a compile time query language while others are done at runtime. This is a major difference because that generated and verified with the compilation and that's not true for other tools that use xml files to map to the database.

> use Integer and Double member variables instead of int and double

Yes, unless using dirty tricks like Integer.MIN_VALUE+x. -10%.

> very deep initialization

I am not sure, but I don't think this is a big problem. You could define a configuration option how deep to initialize. If this value is too low, the query would throw a NullPointerException. -1% (in my view)

> You require a default constructor... Creating instances and setting their members to arbitrary values might have side effects

The O/R mapping tool needs to do that as well. Theoretically it could be a proxy class (a class that extends the class; created at runtime).

> application developers need quite some knowledge

At least they can debug everything - it's pure Java. After you understand how it works there is little magic.

I agree it's not 95%. Let's say 84% ;-)

> Hibernate and Linq

Hibernate is not LINQ: it is DLINQ (dynamic LINQ). As far as I know, the current version of DLINQ is not as easy to use as Hibernate.

Wow, you are pretty fearless when it comes to creating weird dirty tricks to overcome language limitations. I agree that you've found a clever way of integrating query syntax into compilable Java, but that's tough stuff:
- counting integers (globally, interlocked? what do you do at the first overflow - hope the old ones aren't needed? or do you simply require people's classes to use Integer instead of int?)
- defining initialization depths (and thus requiring query programmers to keem them in sync with the depth they actually use - otherwise runtime error or waste)
- ignoring possible side-effects (even a subclass proxy would have its base class constructor called, unless you can prevent constructor calling alltogether, which your statemtent about O/R tools needing to do this as well seems to negate. I'd wonder how Java handles deserialization then, though)
- even then, those side effects could be perfectly welcome for actual objects (e.g. enlisting objects) but not for objects that were never supposed to actually exist (aliases), so the comparison with ORMs doesn't quite fly.

Add to this the ugly syntax of .where(test(A, SMALLER, B)) instead of where a < b, or the set-syntax in .select instead of anonymous types, and even 84% seem to be way off in terms of language integration.

If I were a Java developer, I'd consider using it, because all those drawbacks might be better than having that strong old separation between static code structure and dynamically parsed query _strings_. But still, percentage-wise, this is a brave statement.

BTW:
Afaik, DLINK refers to Data-LINQ, an old name for what was to become LINQ 2 SQL. LINQ 2 SQL is very easy to use, but quite limited in its ORM capabilities. Compared to NHibernate, it looks like an attempt to take a query engine and build an ORM around it as an afterthought. But then, it's been made for a certain kind of problems, and if you don't object to the strong relationship to the SQL Server product, it's a nice library. Comparing LINQ itself to NHibernate makes no sense, because LINQ is a language feature which HNibernate is going to support too. You could compare it to HQL though.

Its great to know that , Linq is compile time query language, but it is important to know that , wht level of flexibility Linq provides as compare to Hibernate in the areas of Composite keys handling, etc.

I'll try again: LINQ is just a language feature, and a concept. LINQ alone has no idea of databases, XML stores or any other data storage and retrieval technology, only a concrete LINQ provider will do this (and support composite keys or not etc). LINQ cannot be compared to Hibernate. .NET developers will probably use LINQ for NHibernate (a provider) soon. However, you can compare Hibernate (or NHibernate with LINQ support) to LINQ 2 SQL, or MS's forthcoming Entity Framework.