Skip to main content

DataModel and RowSet

3 replies [Last post]
rbair
Offline
Joined: 2003-07-08
Points: 0

As I mentioned in earlier threads I am working a lot with rowsets and DataModels. I am currently working on a fairly rich file/image browsing interface using a DataModel. During the course of this development I have needed the following features in DataModel that do not yet exist:

1) Notification of when the setRecordIndex method is called (when it results in moving to a new record index). Since the data model is populated with many rows, it is necessary to notify the bindings whenever the current row changes so they can update their ui components. Therefore, I need a listener here.

2) Navigation methods on DataModel (first, last, next, previous, etc). For the same reason as mentioned in (1), I need to have better navigational methods. Not a big deal.

3) Typed getXXX/setXXX methods. When interacting with a DataModel via Bindings, it isn't a big deal to have a simple getValue() method that returns an object. However, when dealing with DataModels via application code (for instance, in my renderer code that renders the file name, thumbnail, and meta data info) it is a royal pain (and brittle to boot) to have to cast getValue into String, byte[], etc. It would be much better to be like RowSet in this case and have getBytes, getString, etc. The added benefit is that getBytes/getString/etc can coerce the data into the format if necessary. I'm not too sure about the benfits of having setXXX/updateXXX methods...anybody?

4) Insert & Delete methods for adding/removing a record. This has admittedly been omitted up until this point, but needs to be handled.

While looking at this list of requirements it occurred to me that all of this functionality is already defined by the RowSet API. There are a few differences including almost every method in the RowSet api throws SQLException (which is a real burden to have to deal with in client code), but many simularities. RowSet even has a beefy MetaData specification which JDNC will have to support in the end anyway, right?

If DataModel didn't extend RowSet directly, then DataModel may yet want to take a good hard look at RowSet for inspiration in its API.

There are benefits to extending RowSet, such as tools support. A lot of vendors already have nifty tools for ResultSets/RowSets, so adding support for data models might not be difficult. Also, RowSets can be implemented to wrap object models such as a Collection of Customer objects. WebRowSet implementations can be devised to transport this information in a representation agnostic manner (meaning that on the client it could be an object model and on the server it could be a JDBC row set implementation). Bindings can be modified to support a RowSet in place of the current DataModel almost without effort. The biggest difference would be having to handle SQLException.

In fact, the biggest draw back, as far as I see it, is mixing the semantics of DB based functionality (via SQLException, and the getArray, getBlob, etc) with a more pure back end agnostic design such as JDNC.

Rich

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rbair
Offline
Joined: 2003-07-08
Points: 0

> I've been pondering this very idea for the last year
> (leveraging RowSet as the
> base DataModel abstraction) And as you point out,
> it's primary dis-advantage
> is its SQL lineage which permeates the API, even when
> the data might have
> nothing to do with a database. I've been dreaming of
> a "DataSet" superclass :-)

Ya, I thought about that as well :) Put the DataSet super class above ResultSet and viola! I don't suppose that'd be so easy to pull off, and wouldn't be possible until Java 6 :-)

> As we move to add RowSet support into JDNC we should
> consider this for the
> reasons you mention. However, I fear issues with the
> current rowset API & impl
> (pointed out by fellow forum posters and others I've
> spoken with) might make
> this a cumbersome solution.
>
> Aim

I have to agree. I think the SQLness of RowSet leaves us with no real option but to wrap a RowSet with a DataModel and let the DataModel handle catching the SQLExceptions thrown by the RowSet.

The DataModel API *could* be designed as a base interface to ResultSet even though it isn't officially in that position. This would keep the door open for a future version of the JDK to actually extend such an interface which would then make all RowSet implementations DataModels by default. Until then we could provide a RowSetDataModel that would wrap a RowSet.

Rich

Amy Fowler

jdnc-interest@javadesktop.org wrote:

[snip]

> While looking at this list of requirements it occurred to me that all of this functionality is already defined by the RowSet API. There are a few differences including almost every method in the RowSet api throws SQLException (which is a real burden to have to deal with in client code), but many simularities. RowSet even has a beefy MetaData specification which JDNC will have to support in the end anyway, right?
>
> If DataModel didn't extend RowSet directly, then DataModel may yet want to take a good hard look at RowSet for inspiration in its API.
>
> There are benefits to extending RowSet, such as tools support. A lot of vendors already have nifty tools for ResultSets/RowSets, so adding support for data models might not be difficult. Also, RowSets can be implemented to wrap object models such as a Collection of Customer objects. WebRowSet implementations can be devised to transport this information in a representation agnostic manner (meaning that on the client it could be an object model and on the server it could be a JDBC row set implementation). Bindings can be modified to support a RowSet in place of the current DataModel almost without effort. The biggest difference would be having to handle SQLException.
>
> In fact, the biggest draw back, as far as I see it, is mixing the semantics of DB based functionality (via SQLException, and the getArray, getBlob, etc) with a more pure back end agnostic design such as JDNC.

I've been pondering this very idea for the last year (leveraging RowSet as the
base DataModel abstraction) And as you point out, it's primary dis-advantage
is its SQL lineage which permeates the API, even when the data might have
nothing to do with a database. I've been dreaming of a "DataSet" superclass :-)

As we move to add RowSet support into JDNC we should consider this for the
reasons you mention. However, I fear issues with the current rowset API & impl
(pointed out by fellow forum posters and others I've spoken with) might make
this a cumbersome solution.

Aim

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

snpe

On Friday 06 August 2004 05:58 am, Amy Fowler wrote:
> jdnc-interest@javadesktop.org wrote:
>
> [snip]
>
> > While looking at this list of requirements it occurred to me that all of this functionality is already defined by the RowSet API. There are a few differences including almost every method in the RowSet api throws SQLException (which is a real burden to have to deal with in client code), but many simularities. RowSet even has a beefy MetaData specification which JDNC will have to support in the end anyway, right?
> >
> > If DataModel didn't extend RowSet directly, then DataModel may yet want to take a good hard look at RowSet for inspiration in its API.
> >
> > There are benefits to extending RowSet, such as tools support. A lot of vendors already have nifty tools for ResultSets/RowSets, so adding support for data models might not be difficult. Also, RowSets can be implemented to wrap object models such as a Collection of Customer objects. WebRowSet implementations can be devised to transport this information in a representation agnostic manner (meaning that on the client it could be an object model and on the server it could be a JDBC row set implementation). Bindings can be modified to support a RowSet in place of the current DataModel almost without effort. The biggest difference would be having to handle SQLException.
> >
> > In fact, the biggest draw back, as far as I see it, is mixing the semantics of DB based functionality (via SQLException, and the getArray, getBlob, etc) with a more pure back end agnostic design such as JDNC.
>
> I've been pondering this very idea for the last year (leveraging RowSet as the
> base DataModel abstraction) And as you point out, it's primary dis-advantage
> is its SQL lineage which permeates the API, even when the data might have
> nothing to do with a database. I've been dreaming of a "DataSet" superclass :-)
>
> As we move to add RowSet support into JDNC we should consider this for the
> reasons you mention. However, I fear issues with the current rowset API & impl
> (pointed out by fellow forum posters and others I've spoken with) might make
> this a cumbersome solution.
>
> Aim
>
>

We have hibernate.It mean that base data model are POJO java beans and collections
regards

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net