Re: Difference between TYPE_SCROLL_INSENSITIVE and TYPE_SCROLL_SENSITIVE ResultSets
Date: Fri, 6 Feb 2004 17:04:23 -0600
Message-ID: <XfqdnUk8lqYGgLndRVn-gQ_at_comcast.com>
"Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message
news:c00rgp$11frtc$1_at_ID-152540.news.uni-berlin.de...
> The SCROLLing part of ResultSet in JDBC is a design flaw introduced by
At their lowest level, even an RDBMS deals with data row by row, column by
column, and one might say record by record, field by field, since the
underlying structures are just good old data structures. Obviously SQL is
set based, and cursors are inherently evie when there are set based
alternatives, though even the WHERE and SELECT clauses (to name a few) deal
with data row by row.
Cursors make a great deal of sense to move data from (not to) the relational
arena to the non-relational since all SQL sets are made up of
> Assuming that ResultSet are intimately connected or similar to a file
The real problem is that we are stuck with baggage from the record manager
days when it was not only common place to edit records like this, it was the
only way to go. Then they adapted APIs that were good for one thing, and
while suitable (since the sets that are dealt with look to be the same sort
of animal as the record based solution,) are particularly horrible from a
proper software engineering standpoint.
The only problem with this statement is, unfortunately it is much easier to
program using cursors and updatable sets than it is to build a proper
interface between UI and data. It is much easier to read in a "set", update
a value in that cursor, and flush it back to the database server. From what
I have read here in comp.databases.theory, very few readers here are lazy
programmers, but unfortunately there are more lazy programmers than good
programmers (by several orders of magnitude at least!) Clearly when I say
"easier" I am referring to initial effort, not overall effort, but that kind
of thinking went out long long ago.
I don't think I can blame the API writers completely, since it is a matter
of give the fool what he wants (well, the fool with a big wad of cash at
least) or he will go somewhere else. Plus, the people who made these API's
for relational databases likely weren't relational programmers. They were
C++ low level programmers, since for the most part, SQL is not low level
enough to write an operating system in (sign me up for that project!)
So what I am trying to say is I agree, don't scroll cursors. Using them as
a method to fetch the set of data from the server is acceptable (the only
way?) but all of the other stuff you can do with them is for the Foxpro
guys!
> the design committee and has no relation whatsoever with a sound
> programming model,
> pointer that moves among the records of the table and you can "update in
> place", as well as move back and forth, and/or observe updates by other,
> is unreliable and bad engineering for too many reasons to be discussed
> here, unless you have a particular curiosity and/or don't trust me.
Louis Received on Sat Feb 07 2004 - 00:04:23 CET