Skip to main content

[Provocative] Why don't we use RowSet for all bindings

14 replies [Last post]
Anonymous

I took a further look at JDK1.5 JDBC classes, and I found a striking
similarity with the binding 'data' package.

Instead of recreating a DataSource, DataModel, Transaction... why not
use the standard JDBC interfaces for all?

DataModel is a tabular data model, and RowSet is too.

Why not?

--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------

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

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
netsql
Offline
Joined: 2004-03-07
Points: 0

"yes - this was what the DataModel interface was originally intended for -
a simple abstraction for a collection of indexible records where fields
may be accessed by id. underneath could be almost anything - a RowSet,
JavaBean, TableModel, .... This abstraction enabled the binding
implementation to talk in a single language to a data model without
concern over what kind it was dealing with."

Sounds smart.
.V

Nicola Ken Barozzi

jdnc-interest@javadesktop.org wrote:
> Great minds think alike :).
> Check out this thread
http://www.javadesktop.org/forums/thread.jspa?forumID=53&threadID=3851&m....

:-) Cool; shame on me for not searching the archives better.

> When all is said and done I think there are 2 good reasons for NOT
extending RowSet or using it directly as our DataModel.
>
> 1) Semantics. Sounds lame, I know, but those SQLExceptions are going
to bug a lot of people who aren't using SQL

Seems a lame excure ;-)

> 2) Release schedule. If something needs to be changed in RowSet,
> we're hosed.

I doubt that big changes will be done, as it's in the JDK now.

> Most likely we'd end up having to extend RowSet anyway,
> sooner or later.

Or wrapping it... oops, that's what you've done with DataModel! :-)

> I like the argument though, because RowSet DOES contain all of the
> functionality we really need, such as adding/removing rows, tracking
> updates to specific fields, setting/getting values, serialization
> (WebRowSet), etc.
>
> But what about the query associated with the RowSet? Doesn't a RowSet
> have a specific query associated with it? That might be a problem.

Actually no.

Look at your RowSetDataModel... doesn't it have a query associated?
The JavaBeanDataModel could too, using Jakarta Commons JXPath.

It's not in the base interface, but looking at the implementations...

> Another thing to consider is that Jeanette is trying to leverage the
> JGoodies binding API for JDNC. If so, she'll want to bind to something
> "PresentationModel"-ish rather than a RowSet -- not a show stopper
> because we could always extend RowSet and implement some
> PresentationModel-ish interface.

I'm not sure I get this...

> After looking at all of the pros and cons it seemed to me that we'd
> do better with an architecture designed specifically for this task. It's
> not really reinventing the wheel, but rather inventing the rubber tire
> and using it instead of a wood wheel. They'll both probably get the job
> done, but I think we'll get more mileage out of the rubber tire (and a
> lot less bumpy of a ride :)).

It's a pity though that JDBC is actually full with pure SQL database
semantics :-/

--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------

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

rbair
Offline
Joined: 2003-07-08
Points: 0

Great minds think alike :). Check out this thread http://www.javadesktop.org/forums/thread.jspa?forumID=53&threadID=3851&m....

When all is said and done I think there are 2 good reasons for NOT extending RowSet or using it directly as our DataModel.

1) Semantics. Sounds lame, I know, but those SQLExceptions are going to bug a lot of people who aren't using SQL

2) Release schedule. If something needs to be changed in RowSet, we're hosed. Most likely we'd end up having to extend RowSet anyway, sooner or later.

I like the argument though, because RowSet DOES contain all of the functionality we really need, such as adding/removing rows, tracking updates to specific fields, setting/getting values, serialization (WebRowSet), etc.

But what about the query associated with the RowSet? Doesn't a RowSet have a specific query associated with it? That might be a problem.

Another thing to consider is that Jeanette is trying to leverage the JGoodies binding API for JDNC. If so, she'll want to bind to something "PresentationModel"-ish rather than a RowSet -- not a show stopper because we could always extend RowSet and implement some PresentationModel-ish interface.

After looking at all of the pros and cons it seemed to me that we'd do better with an architecture designed specifically for this task. It's not really reinventing the wheel, but rather inventing the rubber tire and using it instead of a wood wheel. They'll both probably get the job done, but I think we'll get more mileage out of the rubber tire (and a lot less bumpy of a ride :)).

Richard

Patrick Wright

Plus, as was pointed out months ago, there is always the option of
back-filling both APIs with a common superset (like DataSet) in the
future, allowing for a sharing of common code in the implementations.

jdnc-interest@javadesktop.org wrote:
> Great minds think alike :). Check out this thread http://www.javadesktop.org/forums/thread.jspa?forumID=53&threadID=3851&m....

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

Kleopatra

Nicola Ken Barozzi wrote:
>
> DataModel is a tabular data model

no - I disagree

Currently it is a sequence of metaData/value pairs. Both metaData and
value can be accessed by name. It's basically one-dimensional with a
slight awareness of the second dimension in the recordIndex/-count
properties.

So I prefer to view it as a pointer/cursor on top of an arbitrary
(indexable) data structure, the values representing data of a fixed
"record" at any given time. As such it is the smallest unit of interest
for a "screen" representation of that record. This screen (or form) is
the collaborator the DataModel was designed for (as I understand it -
might be wrong of course :).

Decoupling the cursor from the underlying structure increases
flexibility, f.i. it "naturally" allows to have multiple cursors on top
of that structure (in theory at least, Richard keeps telling me that we
are getting into update hell if we try to ).

There's a need for a generic "Tabular Data Model" - it would be a
congenial partner for the DataModel - but there's no general need to
hard-couple both abstractions on the interface level. Implementations
are free to do so. If it turns out that the form/binding needs to access
the "table-ness" all the time, we can refactor with little cost (and
I'll have to spend a big beer for Richard )

Okay, back to reading all the very interesting posts which accumulated
since x-mas (seems like nobody did holiday except me :)

Jeanette

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

Amy Fowler

Kleopatra wrote:

> So I prefer to view it as a pointer/cursor on top of an arbitrary
> (indexable) data structure, the values representing data of a fixed
> "record" at any given time. As such it is the smallest unit of interest
> for a "screen" representation of that record. This screen (or form) is
> the collaborator the DataModel was designed for (as I understand it -
> might be wrong of course :).

yes - this was what the DataModel interface was originally intended for -
a simple abstraction for a collection of indexible records where fields
may be accessed by id. underneath could be almost anything - a RowSet,
JavaBean, TableModel, .... This abstraction enabled the binding
implementation to talk in a single language to a data model without
concern over what kind it was dealing with.

I can see why it's tempting to develop it into the mother of all data model
APIs, but I personally don't think we want to constrain all apps to
deal with a DataModel if they'd rather talk in RowSets or JavaBeans (in
which case the DataModel becomes a hidden impl detail within the bindings).

Maybe it's not an either/or decision -- we could support both the barebones
interface (similar to DataModel's birthrite) and a more powerful subclass
with the bells/whistles Rich proposes. [forgive me if sleep depravation
has me arguing off-track -- I'm not necessarily caught up...:-]

Aim

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

rbair
Offline
Joined: 2003-07-08
Points: 0

> Maybe it's not an either/or decision -- we could
> support both the barebones
> interface (similar to DataModel's birthrite) and a
> more powerful subclass
> with the bells/whistles Rich proposes. [forgive me
> if sleep depravation
> has me arguing off-track -- I'm not necessarily
> caught up...:-]

This is the right idea, I think. Have a look at this image to see the diagram I have on my whiteboard at the moment (https://jdnc-incubator.dev.java.net/source/browse/jdnc-incubator/reorg/b...).

The DataSet in this image takes on the mammoth responsibilities of master/detail and interacting with the DataStore like you would for a JDBC based app. However, the DataModel interface is preserved, and the DataSet implements it. If the final design follows something along these lines, then you'd be able to adapt most anything to the binding API as long as it implements the DataModel interface.

It may be (though I cannot say for sure yet) that the DataSet API I'm working on now will be used almost exclusively with JDBC connections, and other API's will be contrived that work better with WebServices. As long as they both implement DataModel, the binding API doesn't really care. Hmmm. Shooting from the hip here...

Richard

rbair
Offline
Joined: 2003-07-08
Points: 0

> It may be (though I cannot say for sure yet) that the
> DataSet API I'm working on now will be used almost
> exclusively with JDBC connections, and other API's
> will be contrived that work better with WebServices.
> As long as they both implement DataModel, the binding
> API doesn't really care. Hmmm. Shooting from the hip
> here...

That being said, I don't want to give the impression that you couldn't use the DataSet API for a multitude of other connections. Indeed, from what I'm looking at now I don't really see why it wouldn't work with any conceivable data store. What I am saying is that I like choice in an API, and being able to swap out the DataSet API and use something else and have it still work with the binding is really a cool idea.

Richard

netsql
Offline
Joined: 2004-03-07
Points: 0

No DAO I know of uses RowSet.
RowSet is a longer interfaces and harder to implement.
What service API supports it? BigDecimals?

1st, you would need a fire wall opened. Then DB passwords.

Does somone think that bypasing a DAO or services and talking to JDBC direct will let you get row #1, before row #100,001 has been sent by the DB? :-)
Not even ODBC lets you do that, that is not how DB drivers work.
It MUST finish retriving the entiere results before its avaialbe.
So driect conetions are just a bad idea.
This is how a DAO does it, pagination.
http://www.jdocs.com/ibatis/2.0.5/api/com/ibatis/sqlmap/client/SqlMapExecutor.html#queryForPaginatedList(java.lang.String,%20java.lang.Object,%20int)

I am for DataSet API, that can be used for both Form (single row, where I use a map) and Grid (table, repepater) and tree and swing.Document.

My specific code example was Lucene. (yes, you can search THIS forum using remote Lucen service).

Some people conect direct to DB in TomCat, it's not a good idea. In anycase, Flex and Sandra offer better alternatives than RowSet as DTO/VO.
I think I made all the points I want to make on this.
.V

netsql
Offline
Joined: 2004-03-07
Points: 0

Becuase not all data comes as JDBC:

1. Take a look at JDNC based boardVU.com -click the search Tab : It uses Lucene! Lucene is a text search tool, no such thing as JDBC in it. It converts to Collection.

2. One uses a DAO such as JDO. *None* of them expose RowSet.
Query q = pm.newQuery("javax.jdo.query.SQL","SELECT * FROM MYTABLE");
Collection c = q.execute();
It's a good idea to allways use a DAO on the server, and hide the implementation of DAO. See, JDO uses a Collection

3. From Flex:
result="empD=event.result" />
var empD;
function initSO() {
empSO.populate(); }
See... they use Associative Arrays.
(A ArrayList of HashMaps).
See how they do it?!

4. It might temp some users to use JDBC and conect to DB directly.

5. Would you realy put in JDNC BluePrints to use a RowSet?

6. That leads to other issues... like using Transactions, Locks, etc in the View/Application layer.

- Like another poster said, how do we bind to Collections?
Which is what Sandra does, and it works, becuase boardVU.com works. (The remote DAO I use is iBatis, it also emits Collections)
You can allways do insance of or getClass.getName.
I wrote all the binding and it works w/ push-pull, model to view comunications.
(I also put my binding methos in the model, it's more OO; not in the view like JDNC does)

We have allways used VO and DTO to allow one layer to change, w/o impact on the other layer. sandraSF will continue to use Collections, and if it has to, over load RowSet APIs.

I just wanted to raise this issue in the M/D thread.

hth,
.V

Nicola Ken Barozzi

jdnc-interest@javadesktop.org wrote:
> Becuase not all data comes as JDBC:

I add: not all data comes as a DataModel!

Just as we have to create implementations that map to a DataModel, we
can with at most the same difficulty do the same with a RowSet instead.

With the added bonus that any JDBC tool can read that data!

> 1. Take a look at JDNC based boardVU.com -click the search Tab : It uses Lucene! Lucene is a text search tool, no such thing as JDBC in it. It converts to Collection.

A Collection can be exposed as JDBC RowSet.

> 2. One uses a DAO such as JDO. *None* of them expose RowSet.
> Query q = pm.newQuery("javax.jdo.query.SQL","SELECT * FROM MYTABLE");
> Collection c = q.execute();

A Collection can be exposed as JDBC RowSet.

> It's a good idea to allways use a DAO on the server, and hide the implementation of DAO. See, JDO uses a Collection
>
> 3. From Flex:
> > result="empD=event.result" />
> > var empD;
> function initSO() {
> empSO.populate(); }
> See... they use Associative Arrays.
> (A ArrayList of HashMaps).
> See how they do it?!

ArrayList of HashMaps can be exposed as JDBC RowSet.

> 4. It might temp some users to use JDBC and conect to DB directly.
>
> 5. Would you realy put in JDNC BluePrints to use a RowSet?

What's so different from a DataModel?

> 6. That leads to other issues... like using Transactions, Locks, etc in the View/Application layer.

We can always encapsulate it in a layer that handles them.

> - Like another poster said, how do we bind to Collections?

ArrayList of HashMaps can be exposed as JDBC RowSet.

> Which is what Sandra does, and it works, becuase boardVU.com works. (The remote DAO I use is iBatis, it also emits Collections)
> You can allways do insance of or getClass.getName.
> I wrote all the binding and it works w/ push-pull, model to view comunications.
> (I also put my binding methos in the model, it's more OO; not in the view like JDNC does)
>
> We have allways used VO and DTO to allow one layer to change, w/o impact on the other layer. sandraSF will continue to use Collections, and if it has to, over load RowSet APIs.

As you said:

"over load RowSet APIs."

> I just wanted to raise this issue in the M/D thread.

A collection is not the most generic thing, as it's *always*
disconnected. A RowSet can also be connected, and that's why using only
a Collection is not always the best thing.

If I have a very big table, with a RowSet I can keep it connected or
cache chunks of it... with a Collection I have to load it *all* in memory.

And since a RowSet is a conceptual superset of Collection, why not use
*that* as a base, instead of recreating all the Rowset stuff as DataModel?

I have seen too many rewrites of existing things to not muse over
reusing stuff that is already there...

--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------

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

netsql
Offline
Joined: 2004-03-07
Points: 0

http://java.sun.com/j2se/1.4.2/docs/api/javax/sql/RowSet.html
You would implement and carry all that? Over a services protocol - that can seralize it?

Connected ... to a DB? So reduce connection pooling?
Connected is a bad idea IMO.

Most every DAO I know of lets you paginate data. I use iBatis for data pagination.

How is this better then other RiA, like Flex, Laszlo, DHTML? They are all clean sepeartion, my UI team is diferent that services team.

I sugest an alternative. Write a ModelApi marker interface that would also work on FormModel, and just add signatures what you need.
I perfer a layer aproach, I would not depend on RowSet Api.
.V

Nicola Ken Barozzi

jdnc-interest@javadesktop.org wrote:
> http://java.sun.com/j2se/1.4.2/docs/api/javax/sql/RowSet.html
> You would implement and carry all that? Over a services protocol - that can seralize it?

No, The Rowset is just an *interface*, exactly like the DataModel.
But differently from a Collection it _can_ also accept connected sources.

> Connected ... to a DB? So reduce connection pooling?
> Connected is a bad idea IMO.
>
> Most every DAO I know of lets you paginate data. I use iBatis for data pagination.

And I use a RowSet ;-)

I mean, isn't a RowSet a conceptual superset of Collection?

> How is this better then other RiA, like Flex, Laszlo, DHTML? They are all clean sepeartion, my UI team is diferent that services team.

I don't know Flex or Laszlo, but DHTML AFAIK is not particularly
brilliant at pagination.

> I sugest an alternative. Write a ModelApi marker interface that would also work on FormModel, and just add signatures what you need.
> I perfer a layer aproach, I would not depend on RowSet Api.

I still don't see why a Collection is better :-)

Mind me, I'm playing the devil's advocate here, and that's why I labeled
this as "provocative".

In the JDK1.5 guide:

"
The JDBCTM API provides universal data access from the JavaTM
programming language. Using the JDBC 3.0 API, you can access virtually
any data source, from relational databases to spreadsheets and flat
files. JDBC technology also provides a common base on which tools and
alternate interfaces can be built.
"

The RowSet was made *exactly* for the purpose of defining a way to
access tabular data. The DataModel is created for defining a way to
access tabular data... why duplicate?

--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------

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

Patrick Wright

Nicola

>
> The RowSet was made *exactly* for the purpose of defining a way to
> access tabular data. The DataModel is created for defining a way to
> access tabular data... why duplicate?
>

There is a very long thread from around six months ago on this list on
DataModel. From what I recall, DataModel was conceived because there
were limitations with RowSet, and RowSet is "owned" by a different group
and specs process, so can't be easily or quickly changed to reflect the
needs of JDNC. Hence the creation of the DataModel class. I seem to
remember that the author (AIM?) was not happy with the compromise, but
there you have it.

I don't know if you have seen that thread, search for "rowset datamodel"
on the list (body search). From 08/04/2004, thread "DataModel and
RowSet", from AIM:

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

This was just one fragment of a very long discussion on the topic (on
more than one list thread). As there was no quick solution for
integrating the needs of the two APIs, the decision was made to keep
them separate, from what I understand.

That thread is very interesting for other reasons if you haven't seen it
yet.

Regards
Patrick

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