Re: approaches for embedding a data language in a general purpose language

Marshall wrote:
> 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.

Perhaps that is the lack of elegance of XQuery on which I think linq is based (which has lots of capability, but definitely lacks elegance due, in part, to the flexibility of XML).

> > 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

Agreed. I really dislike the OR mapping step, preferring that the language of the dbms be much more aligned with the languages accessing the data. SQL is not going to get us there. We need a new language for the DBMS. That is a reason to use Hibernate, hiding the SQL. However, then such abstractions need to have the set processing features too.

> 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.

As much as I dislike OR-M, I think it is important that we get away from SQL. It just isn't the future, in spite of attempts to move it there. XQuery was supposed to be our "And now for something completely different" but the jury is still out. --dawn Received on Tue Oct 10 2006 - 16:42:09 CEST