The JDBC Rowset implementation proposed final draft 2 API docs and reference implementation (RI) is out for public review. The RI provides five standard implementations of the standard JDBC RowSet implementation interface definitions. Among other benefits, Rowsets are a nice replacement for custom data transfer objects for displaying relational data on web pages.
- Posted by: Floyd Marinescu
- Posted on: August 29 2003 13:38 EDT
Check out JDBC Rowsets Implementations Proposed Final Draft 2 and the JSR 114 homepage.
- bad api by Carlo Marchiori on September 01 2003 04:30 EDT
- DataSet Cloned :) by sudhakar sadasivuni on September 01 2003 06:29 EDT
- JDBC RowSet Implementations Public Review II by Jonathan Bruce on September 04 2003 21:13 EDT
This is an example of an api that was copied without thought from Microsoft (ODBC). JDBC does not have such concepts such as database, tables, rows. Everything is shrinked into a single class (namely ResultSet). From this uncomfortable starting point it's very difficult to develop anything good.
This is an example of an api that was copied without thought from Microsoft (ODBC).
Up to a point. It would be great if someone came up with a really good OO model for working with databases and I agree that neither JDBC or ODBC or ADO are perfect. Sun based JDBC on ODBC because it was widely regarded as the best thing around at the time. They added some good new features to it PreparedStaement objects being one (having setString was something for which I shall be eternally grateful), the Resultset Metadata being another (you could build a fairly sophisticated web based adhoc query tool in about half a dozen lines with a Servlet and JDBC hard to imagine that in ODBC at the time). They made it stable (ODBC was horrendously flaky throughout all the time I used it). MS took a lot of these ideas on in ADO (Im not sure about the stability).
But if you were starting again and trying to build on OO API for databases what would it look like?
It would look like JDO (http://java.sun.com/products/jdo)
I think JDBC is a good O.O API for DB, i mean: is a good API for doing SQL SELECTS, INSERTS, UPDATES and playin with arrays of rows ... but may be what a true O.O programmer would like is a O.O API for Object Persistence so it have to write SQL code only when he needs to do complicated queries
voila, you cloned .NET's DataSet atlast.
Sun rleased rowset early access 4 implementation in year 2000, before .NET was released.
Borland Delphi has disconnected dataset implementation (TClientDataSet) in Delphi 3 (year 1997). This implementation is more reacher (more functionality) than both .NET and rowset implementation.
Disconnected dataset is sure not Microsoft invetion.
yes, of course.
I agree also that the future for java
of oo access to rdbms is jdo. It means
that the mapping to rdms is not done *inside*
objects (ejb width cmp), but *outside*,
namely it's an aspect to be added on demand.
this introduces to a more general problem of
how to extract and inject state into a java
object, given the fact that java hides memory
This kind of problem arises whenever
you must write code that *controls* your object
from outside your domain model (a controller).
In the end your application model must be wired
to I/O communication (network data, mouse, keybords,
...). Without the controller concept, objects are useless,
like a platonic inaccessible world of ideas.
Since you can't access java object layout,
in my opinion the language should offer a
a framework for state internalization and
externalization. Java Beans is such a framework,
but it was never seriously supported, since Sun
has proposed other models such as EJB, JMX, ...
Actually this is our public review II and we have made the additional effort to supply our reference implementation classes for you all to try out. I would encourage you all to try our latest drop and send feedback to:
jsr-114-comments at jcp dot org
You can download the RI from here
JDBC Spec. Lead
Sun Microsystems Inc.