Re: approaches for embedding a data language in a general purpose language
Date: 9 Oct 2006 20:27:19 -0700
Message-ID: <1160450839.475066.233780_at_m7g2000cwm.googlegroups.com>
On Oct 9, 2:41 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
> I don't have an answer to your question, but more questions along the
> same line. I don't follow .NET closely, but it looks like they might
> have made a wise decision with the linq projecthttp://msdn.microsoft.com/data/ref/linq/where they decided at some
> point to drop their interest in XQuery being handled like SQL. They
> have extensions to various .NET languages so the developer doesn't
> switch languages when working with data whether in a dbms or not,
> whether SQL or XQuery IIRC).
>
> I haven't played with it, just admired it from a distance, but it seems
> like a good idea to abstract SQL to set up for moving beyond it, even
> though that doesn't sound like it is your specific concern here. I
> also think it is great if you can work with temporary data that is
> unrelated to a dbms the same way you handle data from a dbms. What do
> you think of the linq approach?
I haven't really read any papers on linq lately, so my information may be dated. But my original thought was that, while they were asking the right questions, I wasn't thrilled about their answers. It seemed to me they took rather a kitchen sink approach, and the result had substantial expressive power but lacked elegance.
> SQLJ seems to have lost out to Hibernate in the minds of many Java
> developers. Is that your guess too, and, if so, do you have a guess
> why that is? --dawn
I agree that Hibernate is winning the market.
I haven't yet seen an OR/M that didn't strike me as something akin to those little inflatable duck rings you put on kids to get them used to the pool. They push the programmer hard in the direction of thinking in terms of "get the data back from the dbms; turn it in to objects; modify those objects; update" even though that approach is not typically the right choice. For an extreme example, consider what happens when you want to delete 1 million out of two million rows from table T according to whether it matches predicate e:
ORM approach:
select * from T where e
for (row in result set)
TCollection.add(new TObj(row))
for (TObj t in TCollection)
t.delete();
for (TObj t in TCollection)
t.save()
/* which translates into:
delete from T where T.key = t.key
*/
Direct SQL approach:
delete from T where e
For whatever reason, no reference implementation of SQLJ emerged.
If you wanted it, you probably couldn't get it. (I tried.) So in the
Java
market, embedded SQL lost by default.
Marshall Received on Tue Oct 10 2006 - 05:27:19 CEST