What does everyone else do for graphically displaying data?

On Dec 11, 9:46 am, RedGrittyBrick
wrote:
> mdR wrote:
> > ~hey
>
> > ok--i need to quit researching and testing, and get on with
> > applications. one way or another, make a decision and get back to
> > work.
>
> > what does the majority of programmers do for displaying data in a one-
> > to-many relational database?
>
> > brief history: i come from using Borland Delphi (object-pascal) where
> > it was pretty brainless in setting up editable table/grid displays.
> > moved from there to Java, recognizing the whole platform independant
> > thing and wanting to move forward. so purchased Borland JBuilder...
> > same thing: basically drag and drop components in the ide, set
> > properties and presto, you had an application where you can edit data
> > from a gui. Then came the bomb (for me)--borland removed all such
> > libraries/components from their latest release and dropped all support
> > for there data-aware components. hey-whatever...fortunately their
> > dbms is fully JDBC compliant, so at least i can move forward.
>
> > so after much research, i find that there really is not much for data-
> > aware component libraries for use in ide's out there! i have read the
> > JDBC API reference cover to cover a couple of times, researched these
> > newsgroups quite a bit and just would like to confirm a direction i
> > should be going. you know it's funny--all the examples for jdbc do
> > not have graphical displays (ie: windows)! it is all just console
> > output. hey-even i can do that!
>
> > it appears that i should just forget looking for component libraries
> > and do all the data stuff / graphical stuff in code. for example--can
> > you bind a data grid to a database table so that when you edit the
> > grid cell it updates the table data? how do you do that? is this
> > easily done or does it involve a lot of additional coding?
>
> 1) Use MVC pattern, put all JDBC code in the Model classes. Make use of
> the models that are part of the API for many Swing components. E.g.
> extend AbstractTableModel and put JDBC code there. Use SwingWorker in
> the View classes when invoking lengthy Model methods so that database
> access doesn't block the EDT.
>
> 2) Use something like Hibernate.
>
> 3) I vaguely recall that SwingX had some data-aware components.
>
> 4) DAO?
>
> I suspect that 2 is the canonical answer. When learning Java, I took the
> view that Hibernate looked complex and therefore it was worth learning
> how to use JDBC first.

thanks for reply!

started looking at Hibernate... looks at first blush a little
daunting, but i'll see how it progresses thru the tutorial. It
appears to actually be part of the JBuilder 2007 package; at least
heavily referenced--along with Spring. At first look, it appears
Spring is more of an enterprise solution to database apps(?), at least
reading the intro. they mention Hibernate being more light-weight.
we'll see.

curious--do you still view Hibernate as being complex? i've a ways to
go...

tia
-mark
 >> Stay informed about: What does everyone else do for graphically displaying data? 

mdR wrote:
> curious--do you still view Hibernate as being complex? i've a ways to
> go...



Hibernate appears to have a steeper learning curve than plain JDBC. To
get started with JDBC you can copy some simple examples that only use a
dozen or so lines of code. To get started with Hibernate it appears you
need to follow some rules about class structure, create some XML files
(or annotate your classes) and so on. There's more initial overhead to
set up. From comments I've read in Java newsgroups, I suspect using
Hibernate will pay off in terms of making the whole project take less time.

I'm working on a project with hundreds of classes and several tens of
database tables. This project uses JDBC directly, simply because that
was an arbitrary decision made at the outset. I'd like to find a much
smaller project to try out Hibernate, but no opportunity has arisen yet.

I found that using JDBC directly helped me learn some things about
threading, exception handling and class design that were interesting and
more broadly useful.

Since I haven't used Hibernate, I can't really comment on the specific
circumstances where it might be better to use other approaches such as
using JDBC directly.
 >> Stay informed about: What does everyone else do for graphically displaying data? 

"mdR" wrote in message

> ~hey
>
> ok--i need to quit researching and testing, and get on with
> applications. one way or another, make a decision and get back to
> work.
>
> what does the majority of programmers do for displaying data in a one-
> to-many relational database?
>
> brief history: i come from using Borland Delphi (object-pascal) where
> it was pretty brainless in setting up editable table/grid displays.
> moved from there to Java, recognizing the whole platform independant
> thing and wanting to move forward. so purchased Borland JBuilder...
> same thing: basically drag and drop components in the ide, set
> properties and presto, you had an application where you can edit data
> from a gui. Then came the bomb (for me)--borland removed all such
> libraries/components from their latest release and dropped all support
> for there data-aware components. hey-whatever...fortunately their
> dbms is fully JDBC compliant, so at least i can move forward.
>
> so after much research, i find that there really is not much for data-
> aware component libraries for use in ide's out there! i have read the
> JDBC API reference cover to cover a couple of times, researched these
> newsgroups quite a bit and just would like to confirm a direction i
> should be going. you know it's funny--all the examples for jdbc do
> not have graphical displays (ie: windows)! it is all just console
> output. hey-even i can do that!
>
> it appears that i should just forget looking for component libraries
> and do all the data stuff / graphical stuff in code. for example--can
> you bind a data grid to a database table so that when you edit the
> grid cell it updates the table data? how do you do that? is this
> easily done or does it involve a lot of additional coding?
>
> any help would be greatly appreciated. to me, this appears to be a
> ~very gray area.
> dazed and confused...
> -mark

Why leave the advanced Delphi system and go to Java. Not only are the Delphi
data aware components well developed, but also the available databases are
painless (NexusDB, FlashFiler, Dbsim, etc.), as are the database
managers/explorers. Delphi does make all that easy, and it is rapid
development, so you must have a good reason for switching.
-russell
 >> Stay informed about: What does everyone else do for graphically displaying data? 

On Dec 12, 10:01 am, "RussellT" wrote:
> "mdR" wrote in message
>
>
>
>
>
> > ~hey
>
> > ok--i need to quit researching and testing, and get on with
> > applications. one way or another, make a decision and get back to
> > work.
>
> > what does the majority of programmers do for displaying data in a one-
> > to-many relational database?
>
> > brief history: i come from using Borland Delphi (object-pascal) where
> > it was pretty brainless in setting up editable table/grid displays.
> > moved from there to Java, recognizing the whole platform independant
> > thing and wanting to move forward. so purchased Borland JBuilder...
> > same thing: basically drag and drop components in the ide, set
> > properties and presto, you had an application where you can edit data
> > from a gui. Then came the bomb (for me)--borland removed all such
> > libraries/components from their latest release and dropped all support
> > for there data-aware components. hey-whatever...fortunately their
> > dbms is fully JDBC compliant, so at least i can move forward.
>
> > so after much research, i find that there really is not much for data-
> > aware component libraries for use in ide's out there! i have read the
> > JDBC API reference cover to cover a couple of times, researched these
> > newsgroups quite a bit and just would like to confirm a direction i
> > should be going. you know it's funny--all the examples for jdbc do
> > not have graphical displays (ie: windows)! it is all just console
> > output. hey-even i can do that!
>
> > it appears that i should just forget looking for component libraries
> > and do all the data stuff / graphical stuff in code. for example--can
> > you bind a data grid to a database table so that when you edit the
> > grid cell it updates the table data? how do you do that? is this
> > easily done or does it involve a lot of additional coding?
>
> > any help would be greatly appreciated. to me, this appears to be a
> > ~very gray area.
> > dazed and confused...
> > -mark
>
> Why leave the advanced Delphi system and go to Java. Not only are the Delphi
> data aware components well developed, but also the available databases are
> painless (NexusDB, FlashFiler, Dbsim, etc.), as are the database
> managers/explorers. Delphi does make all that easy, and it is rapid
> development, so you must have a good reason for switching.
> -russell

i'm starting to question that myself!
basically because it makes the applications more capable of being
managed by others within the business besides myself. There are not
too many out there that are Delphi capable Java ~appears~ to be
more portable than others and secure in the future(?) (and I don't
want to switch to C++).

-mark
 >> Stay informed about: What does everyone else do for graphically displaying data? 

On Dec 12, 6:07 pm, mdR wrote:
> On Dec 12, 10:01 am, "RussellT" wrote:
>
>
>
> > "mdR" wrote in message
>
> >
>
> > > ~hey
>
> > > ok--i need to quit researching and testing, and get on with
> > > applications. one way or another, make a decision and get back to
> > > work.
>
> > > what does the majority of programmers do for displaying data in a one-
> > > to-many relational database?
>
> > > brief history: i come from using Borland Delphi (object-pascal) where
> > > it was pretty brainless in setting up editable table/grid displays.
> > > moved from there to Java, recognizing the whole platform independant
> > > thing and wanting to move forward. so purchased Borland JBuilder...
> > > same thing: basically drag and drop components in the ide, set
> > > properties and presto, you had an application where you can edit data
> > > from a gui. Then came the bomb (for me)--borland removed all such
> > > libraries/components from their latest release and dropped all support
> > > for there data-aware components. hey-whatever...fortunately their
> > > dbms is fully JDBC compliant, so at least i can move forward.
>
> > > so after much research, i find that there really is not much for data-
> > > aware component libraries for use in ide's out there! i have read the
> > > JDBC API reference cover to cover a couple of times, researched these
> > > newsgroups quite a bit and just would like to confirm a direction i
> > > should be going. you know it's funny--all the examples for jdbc do
> > > not have graphical displays (ie: windows)! it is all just console
> > > output. hey-even i can do that!
>
> > > it appears that i should just forget looking for component libraries
> > > and do all the data stuff / graphical stuff in code. for example--can
> > > you bind a data grid to a database table so that when you edit the
> > > grid cell it updates the table data? how do you do that? is this
> > > easily done or does it involve a lot of additional coding?
>
> > > any help would be greatly appreciated. to me, this appears to be a
> > > ~very gray area.
> > > dazed and confused...
> > > -mark
>
> > Why leave the advanced Delphi system and go to Java. Not only are the Delphi
> > data aware components well developed, but also the available databases are
> > painless (NexusDB, FlashFiler, Dbsim, etc.), as are the database
> > managers/explorers. Delphi does make all that easy, and it is rapid
> > development, so you must have a good reason for switching.
> > -russell
>
> i'm starting to question that myself!
> basically because it makes the applications more capable of being
> managed by others within the business besides myself. There are not
> too many out there that are Delphi capable Java ~appears~ to be
> more portable than others and secure in the future(?) (and I don't
> want to switch to C++).
>
> -mark

p.s. forgot also--one of the major factors is Java is the only hook
into one of our major engineering software packages. L8r
 >> Stay informed about: What does everyone else do for graphically displaying data? 

On Dec 11, 9:46 am, RedGrittyBrick
wrote:
> mdR wrote:
> > ~hey
>
> > ok--i need to quit researching and testing, and get on with
> > applications. one way or another, make a decision and get back to
> > work.
>
> > what does the majority of programmers do for displaying data in a one-
> > to-many relational database?
>
> > brief history: i come from using Borland Delphi (object-pascal) where
> > it was pretty brainless in setting up editable table/grid displays.
> > moved from there to Java, recognizing the whole platform independant
> > thing and wanting to move forward. so purchased Borland JBuilder...
> > same thing: basically drag and drop components in the ide, set
> > properties and presto, you had an application where you can edit data
> > from a gui. Then came the bomb (for me)--borland removed all such
> > libraries/components from their latest release and dropped all support
> > for there data-aware components. hey-whatever...fortunately their
> > dbms is fully JDBC compliant, so at least i can move forward.
>
> > so after much research, i find that there really is not much for data-
> > aware component libraries for use in ide's out there! i have read the
> > JDBC API reference cover to cover a couple of times, researched these
> > newsgroups quite a bit and just would like to confirm a direction i
> > should be going. you know it's funny--all the examples for jdbc do
> > not have graphical displays (ie: windows)! it is all just console
> > output. hey-even i can do that!
>
> > it appears that i should just forget looking for component libraries
> > and do all the data stuff / graphical stuff in code. for example--can
> > you bind a data grid to a database table so that when you edit the
> > grid cell it updates the table data? how do you do that? is this
> > easily done or does it involve a lot of additional coding?
>
> 1) Use MVC pattern, put all JDBC code in the Model classes. Make use of
> the models that are part of the API for many Swing components. E.g.
> extend AbstractTableModel and put JDBC code there. Use SwingWorker in
> the View classes when invoking lengthy Model methods so that database
> access doesn't block the EDT.
>
> 2) Use something like Hibernate.
>
> 3) I vaguely recall that SwingX had some data-aware components.
>
> 4) DAO?
>
> I suspect that 2 is the canonical answer. When learning Java, I took the
>
view that Hibernate looked complex and therefore it was worth
learning
> how to use JDBC first.

any thoughts on Spring? or Cayenne?

I guess I'm a little gun shy on committing to one or the other. After
buying into Borland's hype on JBuilder (pre-2007) and then them
bailing on their DataExpress in the latest release... i'm just trying
to setup a successful future. yeah-yeah--nothing is ever for sure,
but with so much out there, just want to make a somewhat intelligent
decision

Pure JDBC and TableModels seems incredibly cumbersome, at least to me,
coming from such a rich library in past ide's. I am starting to grasp
the abstracttablemodel concept, but putting it all together with swing
components is still confusing (all that "magic" was hidden before).
And especially with one-to-many (master-detail) relational data. How
to update from the Swing component edits to the underlying data....

A simple table is one thing, but a multi-table relational database is
another. I like what I've read about Cayenne. It seems this is what
I need to do, but I'm not sure. Anyone have any experience with this?

-mark
 >> Stay informed about: What does everyone else do for graphically displaying data? 

> <snip>
> I like to work with a PostgreSQL database hookup, and just build and tear down
> tables in parallel with the application programming. NetBeans and Eclipse
> both have active editor windows that know what to do with a database link.
> From time to time I pop into a command window and use psql, the command-line
> interpreter. (That also lets me experience concurrent access.)
>
> When in an RDBMS, don't think like a Java programmer. Think like a database
> person.
>
> Architecturally, this separates the business logic from the data layer by
> messages. "I need to know all the addresses for this company," your business
> logic demands. The database serves up a set of rows, the DAO loads the
> columsn into object fields, and Bob's your uncle.
> <snip>

first off--thanks for such a concise reply, it helps...

i think it's easy enough to do as you say to simply display data, but
editing and updating the data is where i'm having problems--coming
from an environment where all the objects are data-aware and the
updating happens automatically behind the curtain. so given a set of
rows from a JOIN, populate text fields, then edit one of the details,
how to get the updated data back to the db? i've looked at some good
examples and it ~appears things are managed by sync'ing a primary key
in all the objects needed to display data. fire a change event in the
graphical objects, which lets the data object know to retrieve values
from the display and execute an update to the db. but what tables to
update? or do i simply update the rowset initially served up by the
join and send that back to the db and it is distributed automatically
to the appropriate joined tables? hmmm... i've got to check into
that... maybe that's part of knowing SQL well...

anyway, one good example i've traced worked with only one table and
even that got kind of complicated managing one key id between db
objects and various gui objects. i guess there was ~a lot~ happening
behind the curtain that i've got to learn iyo-does it ever get
easy?

-mark
 >> Stay informed about: What does everyone else do for graphically displaying data? 

mdR wrote:
> anyway, one good example i've traced worked with only one table and
> even that got kind of complicated managing one key id between db
> objects and various gui objects. i guess there was ~a lot~ happening
> behind the curtain that i've got to learn iyo-does it ever get
> easy?

Easier, yes, easy, no.

The matter of keys is complicated by a tendency for some to overuse integer
surrogate keys, without identifying the so-called "natural" key that at least
ideally identifies the row based on the attributes represented by the columns.

The "key id" I take you to mean is an integer SEQUENCE surrogate key
maintained by the database to help determine row uniqueness, yes?

This surrogate key should be managed by the database - your object should use
it, if at all, only as a very low-level handle for a database row, not for the
object' own purposes. Sequenced surrogate keys exist only to make the
database simpler, and are not (typically) part of the data model. (We'll
ignore certain exceptions.) One should instead understand a row in the
database to be determined by a "natural" column or set of columns, and usually
there should be a UNIQUE constraint on that set of columns. [1]

Think of the object model - these attributes would be the ones that determine
equals() in your object model.

The integer surrogate key should be determined, if you even need it at all,
which you really don't, actually, except sometimes to underpin DAO layer
machinery, by looking it up from the database, and in no wise should the
middleware attempt to set or change it.

So you shouldn't any more have trouble "managing" (translation: "mucking
with") the key ids.

[1]
"But so-called 'natural' keys can change in real life! People change SSNs all
the time!" No, they don't do it all the time. They do it rarely. And when
they do, it'll screw up your database schema. Then you'll fix it, manually.
At which point their new SSN will uniquely identify them, so the key will
still work as a key.

Don't get me started on data warehouse schemas. They're part of what make me
so cynical about transaction db schemas.

--
Lew
 >> Stay informed about: What does everyone else do for graphically displaying data? 

Lew wrote:
> mdR wrote:
>> anyway, one good example i've traced worked with only one table and
>> even that got kind of complicated managing one key id between db
>> objects and various gui objects. i guess there was ~a lot~ happening
>> behind the curtain that i've got to learn iyo-does it ever get
>> easy?
>
> Easier, yes, easy, no.
>
> The matter of keys is complicated by a tendency for some to overuse
> integer surrogate keys, without identifying the so-called "natural" key
> that at least ideally identifies the row based on the attributes
> represented by the columns.
>
> The "key id" I take you to mean is an integer SEQUENCE surrogate key
> maintained by the database to help determine row uniqueness, yes?
>
> This surrogate key should be managed by the database - your object
> should use it, if at all, only as a very low-level handle for a database
> row, not for the object' own purposes. Sequenced surrogate keys exist
> only to make the database simpler, and are not (typically) part of the
> data model. (We'll ignore certain exceptions.) One should instead
> understand a row in the database to be determined by a "natural" column
> or set of columns, and usually there should be a UNIQUE constraint on
> that set of columns. [1]
>
> Think of the object model - these attributes would be the ones that
> determine equals() in your object model.
>
> The integer surrogate key should be determined, if you even need it at
> all, which you really don't, actually, except sometimes to underpin DAO
> layer machinery, by looking it up from the database, and in no wise
> should the middleware attempt to set or change it.
>
> So you shouldn't any more have trouble "managing" (translation: "mucking
> with") the key ids.
>
> [1]
> "But so-called 'natural' keys can change in real life! People change
> SSNs all the time!" No, they don't do it all the time. They do it
> rarely. And when they do, it'll screw up your database schema. Then
> you'll fix it, manually. At which point their new SSN will uniquely
> identify them, so the key will still work as a key.
>
> Don't get me started on data warehouse schemas. They're part of what
> make me so cynical about transaction db schemas.
>

I disagree with your view on natural keys versus what you call surrogate
keys. The equals definition for a Point class would compare (x,y) tuples
where a Polyline class could contain a Collection of Points and have an
equals definition that compares the contained Points.
To represent a number of Polylines in a database you would have to give
the Polyline some form of key, comparable with the objects identity it
has in the Java program. Primary keys are more comparable with == than
with equals.

Regards,

Silvio Bierman
 >> Stay informed about: What does everyone else do for graphically displaying data? 

Silvio Bierman wrote:
> I disagree with your view on natural keys versus what you call surrogate
> keys. The equals definition for a Point class would compare (x,y) tuples
> where a Polyline class could contain a Collection of Points and have an
> equals definition that compares the contained Points.
> To represent a number of Polylines in a database you would have to give
> the Polyline some form of key, comparable with the objects identity it
> has in the Java program. Primary keys are more comparable with == than
> with equals.

Good work. You found an important use case for integer keys, albeit not
auto-sequenced ones, in a scenario different from the one I described but
related. The differences are important, and explain why this scenario is not
the one to which I alluded upthread.

To represent the polylines in the database I'd have an integer column
representing the order of the points in the Polyline, combined with a foreign
key reference to the Polyline. There'd be no sequenced integer key at all in
the polyline table, just ( polyline_id, point_seq ) as the PK. I would never
compare polyline rows in the database to each other point by point; the
concept of value equality is not relevant to it.

Since the point order is significant, it cannot be auto-sequenced by the
database. It's part of the data model, and therefore part of the natural key.

To represent multiple polylines one must have a similar key, ( vertex_id,
polyline_id). This is one of the exceptions to which I alluded in my post.
Again, I'd probably not use an auto-sequenced key, since I want to keep the
sequence local to the vertex_id. Furthermore, the object model needs to be
able to tell the polylines apart; however, the object has itself as a natural
key, which the db row does not. The polyline_id, sequence or not, stands in
for the object reference. Again, the concept of value equality is not
relevant - I doubt very much that you'd compare polylines point by point in
your object model either. You'd use ==.

In this case the numeric ID, for which I would not use an auto-sequence,
actually is part of the data model. (That's why I wouldn't use an
auto-sequence.) Therefore it actually is part of the "natural" key, along
with the vertex_id. You use an integer column to model the object identity
reference.

My earlier comments were about a different scenario from this, where the
integer is a synonym for a natural key, not actually part of the natural key.
I specifically spoke of auto-sequenced integer surrogate keys; this scenario
has an integer natural key column that should not be auto-sequenced.

--
Lew
 >> Stay informed about: What does everyone else do for graphically displaying data? 

i am thinking along the 'natural' key process, where a unique column
key identifies the row. in line with more traditional columned/
tabulated data and a unique identifier that is assigned by me.

just thinking... are you referring at all to storing persistent
objects rather than raw data? (i am not very familiar with object
persistence).

-mark
 >> Stay informed about: What does everyone else do for graphically displaying data? 

mdR wrote:
> i am thinking along the 'natural' key process, where a unique column
> key identifies the row. in line with more traditional columned/
> tabulated data and a unique identifier that is assigned by me.

A "natural" key might have one column, or several.

The important thing is to identify the key for the row.

> just thinking... are you referring at all to storing persistent
> objects rather than raw data? (i am not very familiar with object
> persistence).

The question has no meaning.

What I refer to in a relational database is the storage of rows and columns in
tables. In the post to which you replied there was no mention of "persistent
objects" nor of "raw data".

I have no idea what you think happens "rather than" what else. The "rather
than" phrase implies a tension or conflict that I do not perceive.

There is a mapping between table rows, perhaps joined in a view, and the
object model, of course. There always is.

Managing that mapping is the job of the data-access layer (or "Data Access
Object" layer, the "DAO" layer).

So what gets stored is "raw" data (whatever that means [1]) that can be used
to persist what the software sees as object data.

If the logic can re-create an object from persistent storage, by definition
that's a persistent object. What gets stored isn't an object, it's data.
What gets restored from that data might be an object.

[1] What makes data "raw"? What characterizes data that is not "raw"?

--
Lew
 >> Stay informed about: What does everyone else do for graphically displaying data?