Advanced Java Servlet API discussion

David M. Lehrian | 16 Dec 2002 03:15

Re: map with java.

Hi Nic,
I too have grappled with the best way to abstract an SQL data model. The mapping concept that you outline
certainly looks workable, but it seems like a lot of code needs to be written for each table you want to map.
i.e. create the interface, get the connection, formulate the query and code the mapper to handle the
result set (doesn't solve the first problem you mention). I am guessing that the idea is to get data from the
database into HTML as quickly as possible in a manner that doesn't cause a new object to be allocated for
each row in the result set (solves the second problem you mention). It just doesn't seem to do that much for
you.

I prefer the Object-Relational mapping method whereby each row is turned into a real java object and handed
back to the programmer as an ArrayList of objects. They can then be programmed to have many different
output "views". And rather than hand code each individual persistent object, I prefer to store the
mapping information in an XML file and use an abstract superclass to create the actual java objects and
populate their data. I wrote such an O-R mapping layer and a graphical modeling tool that generates the
necessary XML mapping files, the SQL to create the database and the persistent Java objects. It is
available at http://www.redshift.com/~lehrian/DMLDataAccess. It implements to-one and to-many
relationships and will sort them if set up to do so in the model. As it is written in a thread safe manner I have
been able to use it for all my work including servlet/JSP development. If there were ever interest, I would
opensource the code. I have an example of how it i
s used in a servlet on the web site.
Warm Regards,
Dave

_______________________________________________
David M. Lehrian
Software Engineer
http://www.easypetidtags.com/
http://www.redshift.com/~lehrian/DMLDataAccess
http://www.redshift.com/~lehrian/JDBCQueryTool
http://www.redshift.com/~lehrian

(Continue reading)

headers

Nic Ferrier | 16 Dec 2002 14:06

Re: map with java.

"David M. Lehrian" <david <at> lehrian.com> writes:

> Hi Nic,
> I too have grappled with the best way to abstract an SQL data model.
> The mapping concept that you outline certainly looks workable, but it
> seems like a lot of code needs to be written for each table you want
> to map.  

I don't tend to use tables directly, I tend to abstract all my querys
with procs that return ResultSets. Of course, there is still a tabular
structure at the end of the day but I think of it more as calling a
proc which generates a stream of rows of a certain type.

> i.e.  create the interface, get the connection, formulate the
> query and code the mapper to handle the result set (doesn't solve the
> first problem you mention).  

It does solve that problem, the iteration is done within the confines
of a method dedicated to the database glue. The connection gets
closed when the mapping completes.

> I am guessing that the idea is to get data from the database into
> HTML as quickly as possible in a manner that doesn't cause a new
> object to be allocated for each row in the result set (solves the
> second problem you mention).  It just doesn't seem to do that much
> for you.

What mapping does is seperate the output of the row data from the
means of obtaining the row data. Obtaining the row data (after the
stored proc has been written) is the sort of thing that can be written

(Continue reading)

headers

David M. Lehrian | 16 Dec 2002 21:12

Re: map with java.

"David M. Lehrian" <david <at> lehrian.com> writes:

>> Hi Nic,
>> I too have grappled with the best way to abstract an SQL data model.
>> The mapping concept that you outline certainly looks workable, but it
>> seems like a lot of code needs to be written for each table you want
>> to map.  

>I don't tend to use tables directly, I tend to abstract all my queries
>with procs that return ResultSets. Of course, there is still a tabular
>structure at the end of the day but I think of it more as calling a
>proc which generates a stream of rows of a certain type.

I guess this is where I differ in opinion concerning database access.  I don't think application
programmers should have to program the plumbing for database access.  Queries, stored procs,
transactions, inserts, updates, deletes result sets and cursors are all database constructs that
unless a programmer is versed in already have a steep learning curve.  I like OR mapping layers because they
insulate the application programmer from the database.  OR mapping layers (at least my layer) also tracks
inserted updated and deleted objects and commits them all in a single database transaction so that the
programmer doesn't have to keep track of this information at the application level.  

Also, if you have stored procs that access a certain table and something about the table changes like the
name of a column or the name of the table, the stored procs all need to be maintained.  With a mapping layer,
the mapping files simply need to be updated.  

From a performance standpoint stored procs are faster to execute, but from a maintenance issue, they are
more difficult to maintain.  That being said I used a stored proc to obtain the primary keys if the database
supports stored procs.  

>> i.e.  create the interface, get the connection, formulate the

(Continue reading)

headers

Nic Ferrier | 16 Dec 2002 22:39

Re: map with java.

"David M. Lehrian" <david <at> lehrian.com> writes:

> I guess this is where I differ in opinion concerning database
> access.

This is all worth discussing here: I think things like OR mapping
technologies are interesting, but one of the things that interests me
is the reinvention of the old way of doing things from the C/C++ days
when bitter battles were fought over the demarcation lines for
applications and stored procs were generally thought to have won out.
It's interesting that different syntax (namely XML) is now seen as
another alternative to stored procs.

> Also, if you have stored procs that access a certain table and
> something about the table changes like the name of a column or the
> name of the table, the stored procs all need to be maintained.  With a
> mapping layer, the mapping files simply need to be updated.

Yeah, and with stored procs only the proc code needs to change. It's a
disenguous argument. 

Procs are different from OR because they are not purely
declarative. That's what makes them popular: they're pragmatic.

> From a performance standpoint stored procs are faster to execute, but
> from a maintenance issue, they are more difficult to maintain.  That
> being said I used a stored proc to obtain the primary keys if the
> database supports stored procs.

I don't buy the maintenance argument at all. The relative maintenance

(Continue reading)

headers

David M. Lehrian | 17 Dec 2002 03:26

Re: map with java.

>"Nic Ferrier" writes:
>This is all worth discussing here: I think things like OR mapping
>technologies are interesting, but one of the things that interests me
>is the reinvention of the old way of doing things from the C/C++ days
>when bitter battles were fought over the demarcation lines for
>applications and stored procs were generally thought to have won out.
>It's interesting that different syntax (namely XML) is now seen as
>another alternative to stored procs.

I do remember the wars over stored procs and application code.  I have always been a hold out for the
application code.  I just find it easier to design and maintain because.  I have always held the
Model-View-Controller paradigm as a good design model and to that end like what OR layers do.  

>Yeah, and with stored procs only the proc code needs to change. It's a
>disenguous argument. 

Actually every proc that references the changed table needs to change.  In my layer the application uses one
name while the database can use whatever name it wants.  If the database name changes, the name in the map is
updated and the application code is not touched.  This eliminates extensive regression testing as would
be needed to make sure every stored proc was updated properly.  

> <snip> they're pragmatic.

Yes they are.  Perl is pragmatic also, but I wouldn't want to maintain an order management system written in
it.  

>I don't buy the maintenance argument at all. The relative maintenance
>cost depends on all sorts of things. I'm an experienced PL/SQL
>programmer, maintaining stored procs costs me very little. I find
>junior programmers find it very easy to learn how stored procs work

(Continue reading)

headers

Kuassi Mensah | 16 Dec 2002 23:06

Re: map with java.

on stored procedures and portability, have you considered Java-based stored
procedures?
although each database vendor has it's own deployment artifacts -- there is no
.ear/.war equivalent, yet -- the code should portable

Kuassi

Nic Ferrier wrote:

> "David M. Lehrian" <david <at> lehrian.com> writes:
>
> > I guess this is where I differ in opinion concerning database
> > access.
>
> This is all worth discussing here: I think things like OR mapping
> technologies are interesting, but one of the things that interests me
> is the reinvention of the old way of doing things from the C/C++ days
> when bitter battles were fought over the demarcation lines for
> applications and stored procs were generally thought to have won out.
> It's interesting that different syntax (namely XML) is now seen as
> another alternative to stored procs.
>
> > Also, if you have stored procs that access a certain table and
> > something about the table changes like the name of a column or the
> > name of the table, the stored procs all need to be maintained.  With a
> > mapping layer, the mapping files simply need to be updated.
>
> Yeah, and with stored procs only the proc code needs to change. It's a
> disenguous argument.
>

(Continue reading)

headers

Nic Ferrier | 16 Dec 2002 23:41

Re: map with java.

Kuassi Mensah <Kuassi.Mensah <at> oracle.com> writes:

> on stored procedures and portability, have you considered Java-based stored
> procedures?

I have. I even wrote some code to allow me to integrate Java and
PostgreSQL (via GNU's GCJ compiler). However, having used it a couple
of times I found that I could always do what I wanted to do much
better with a higher level language.

What I _would_ like is a better database stored proc language than
PL/SQL. I am working on plugging GUILE (a GNU LISP) into
PostgreSQL.

If that doesn't work I'll probably use Python.

> although each database vendor has it's own deployment artifacts --
> there is no .ear/.war equivalent, yet -- the code should portable

As I have said: portability is not really an issue for me. It isn't
for a lot of open source programmers, we code to the platform that
works best.

And I don't think you really need an deployment descriptor for
procs. Unless perhaps you're going to insist on security restrictions.

Nic

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!

(Continue reading)