searching for yoda - a developer's tale

D

dexter

Hello,

if there are any wise and knowing individuals reading this who might be
able to set me on the true path, i'd be indebted.

So, the story goes: I've been a Java developer for a great long while,
but in a *very* sheltered community - I don't know and haven't used a
great many of what have become standard technologies. Most every
significant project involves a number of headaches that I believe have
been solved by said technologies.

I code with vi and build with hand-made scripts. I handle versioning
with hand-made scripts. I use no GUI builder and write JDBC to handle
persistence.

I'm made aware of (and reasonably sold on) eclipse
(http://www.eclipse.org). This can be made to include a GUI builder
(http://www.eclipse.org/vep/) and handle versioning through cvs
(https://www.cvshome.org/). There's also a thing called MyEclipse
(http://www.myeclipseide.com) which I know nothing about.

I *hate* writing SQL in seperate DAO's and worrying about a handcoded
persistence manager, connection caching, etc. This should be
automated. I search for a while and find the community has largely
come to like Hibernate (http://www.hibernate.org). There are even
plug-ins for Eclipse: Hibernator (http://hibernator.sourceforge.net/),
Hibernate Synchronizer (http://hibernatesynch.sourceforge.net/), and
Hiberclipse (http://hiberclipse.sourceforge.net/) are all mentioned in
an article
(http://www.onjava.com/pub/a/onjava/2005/01/05/hibernate.html).

Hibernate Synchronizer seems to have the largest community, so I look
into it further. Looks like the empahsis is on going from a mapping
file to a db and Java code. There is a thing called middlegen
(http://boss.bekk.no/boss/middlegen/) that lets you start from the db
-- but what I'm good at is Java...

Ah ha, one can make Java generate the mapping file if one uses XDoclet
(http://xdoclet.sourceforge.net/xdoclet/index.html), and the XDoclet
hibernate plug-in (http://xdoclet.codehaus.org/Hibernate+plugin)
....sort of -- many references hint at bugs. XDoclet uses lower layers
to do its work which I'm not sure one needs to master independantly,
but they include Generama, Velocity, and Freemaker...

All of this of course requires Ant (http://ant.apache.org/), although
the XDoclet example for Ant is missing -- no worries, it does include
an example using Maven (http://maven.apache.org/). All of the set-up
for darn near everything uses XML of course, and there's an xml editor
plug-in for Eclipse -- XMLBuddy (http://www.xmlbuddy.com/)

Most of the Hibernate examples use the HSQLDB
(http://hsqldb.sourceforge.net/) for development.

That's a boatload of technologies folks. I've got active projects for
which I'd like to use Eclipse/Hibernate and don't have the time (I've
wasted far too long already) to fully investigate and learn all this.
What is the proper path through this open-source forest?

Kind regards,

-don.
 
R

Rhino

Hello,

if there are any wise and knowing individuals reading this who might be
able to set me on the true path, i'd be indebted.

So, the story goes: I've been a Java developer for a great long while,
but in a *very* sheltered community - I don't know and haven't used a
great many of what have become standard technologies. Most every
significant project involves a number of headaches that I believe have
been solved by said technologies.
So far, that's not terribly unique; the vast majority of us have not used at
least SOME of the popular tools and technologies. Some of us may have been
as sheltered as you or even more so. (I'm thinking of some of the newbies
who have just started Java: some of them may not have any significant
systems experience at all and may be using Java as their first programming
language.)

In other words, you're not THAT far off the beaten path, so don't get TOO
concerned ;-)
I code with vi and build with hand-made scripts. I handle versioning
with hand-made scripts. I use no GUI builder and write JDBC to handle
persistence.
If that works for you, it shouldn't be a cause for immediate concern. Of
course, you may find that you would get some serious productivity gains by
looking at some of the newer tools and technologies.
I'm made aware of (and reasonably sold on) eclipse
(http://www.eclipse.org). This can be made to include a GUI builder
(http://www.eclipse.org/vep/) and handle versioning through cvs
(https://www.cvshome.org/). There's also a thing called MyEclipse
(http://www.myeclipseide.com) which I know nothing about.

I *hate* writing SQL in seperate DAO's and worrying about a handcoded
persistence manager, connection caching, etc. This should be
automated. I search for a while and find the community has largely
come to like Hibernate (http://www.hibernate.org). There are even
plug-ins for Eclipse: Hibernator (http://hibernator.sourceforge.net/),
Hibernate Synchronizer (http://hibernatesynch.sourceforge.net/), and
Hiberclipse (http://hiberclipse.sourceforge.net/) are all mentioned in
an article
(http://www.onjava.com/pub/a/onjava/2005/01/05/hibernate.html).

Hibernate Synchronizer seems to have the largest community, so I look
into it further. Looks like the empahsis is on going from a mapping
file to a db and Java code. There is a thing called middlegen
(http://boss.bekk.no/boss/middlegen/) that lets you start from the db
-- but what I'm good at is Java...

Ah ha, one can make Java generate the mapping file if one uses XDoclet
(http://xdoclet.sourceforge.net/xdoclet/index.html), and the XDoclet
hibernate plug-in (http://xdoclet.codehaus.org/Hibernate+plugin)
...sort of -- many references hint at bugs. XDoclet uses lower layers
to do its work which I'm not sure one needs to master independantly,
but they include Generama, Velocity, and Freemaker...

All of this of course requires Ant (http://ant.apache.org/), although
the XDoclet example for Ant is missing -- no worries, it does include
an example using Maven (http://maven.apache.org/). All of the set-up
for darn near everything uses XML of course, and there's an xml editor
plug-in for Eclipse -- XMLBuddy (http://www.xmlbuddy.com/)

Most of the Hibernate examples use the HSQLDB
(http://hsqldb.sourceforge.net/) for development.

That's a boatload of technologies folks. I've got active projects for
which I'd like to use Eclipse/Hibernate and don't have the time (I've
wasted far too long already) to fully investigate and learn all this.
What is the proper path through this open-source forest?
I wish I had a perfect answer for you but the fact is that no one can tell
you the best way to learn things without knowing you pretty well. I've done
quite a bit of teaching of computer courses in my career (in private
industry, not in the school systems) and I've found that there are several
different ways of learning; no particular method is best for everyone. Some
people can hear something described in a lecture and then apply it
immediately with the help of a reference manual. Some people can work
through a tutorial on their own and pick up what they need to know. Some
people can figure out everything they need from the reference manual alone.
And so on. No one could possibly tell you the best way for YOU to learn.

A lot of people have not even figured out how they best learn. They may
remember one "learning experience" favourably and another unfavourably but
they may never have analyzed why one approach worked really well and why
another failed miserably. If you haven't thought about it yourself, I would
strongly advise that you analyze which approaches have worked best for you.

Then, if your best approach happens to be classroom courses, look for
courses that cover the material you want to learn - and ask here if you have
trouble finding them. Maybe someone here can point you to a course that
would meet your needs. While courses can be expensive, they can also be a
very efficient way to learn something. [I remember an early employer handing
me a poorly-written IMS manual and inviting me to learn how to code
database calls from it. It took me a few months to get even a working
knowledge and roughly a year of trial-and-error coding to get fluent with
IMS; if they had spent the money to send me on a lousy three day course, I
would have been fluent in MUCH less time!]

If your best approach turns out to be tutorials, ask here if you need help
finding tutorials for the topics that interest you. And so on for all of the
different approaches.

Of course, you may have to settle for your second or third choice: if you
thrive on classroom courses but there isn't one for your topic, you may have
to settle for a tutorial or reference manual.

The other thing you should evaluate is why you want to learn these
technologies. If it is only for "bragging rights", I'm not sure if learning
these techniques is a good use of your time. If you want to be more
productive - do better work in less time - that seems like a much better
reason to me. In that case, you might ask people here what tools most helped
their productivity and then look at those as your first priorities.

For what it's worth, the only technologies you describe which I use
regularly are Eclipse and Ant. I also dabble in XML occasionally. I've never
used Hibernate or Maven or middlegen or XDoclet and, truthfully, don't even
know what they do. I'm vaguely curious about them but not enough to actually
investigate them ;-) My existing methods seem to work just fine for me so
"if it works, don't fix it".

Maybe you should drive your attempts to learn new tools by the problems you
are having. If SQL and JDBC are your biggest hassles right now - the ones
that eat the most of your valuable time - maybe you should start by trying
to replace them with 'friendlier' tools. Then, as you solve each problem
area, move on to another technology and add it to your bag of tricks.

My two cents worth,

Rhino
 
D

dexter

Thanks for the input. Valid points all.

My motivation comes from two related drives: 1) better productivity,
and 2) starting to do things in a "more standard" way. The rationale
for (2) being that it's likely that folks in the open source community
have thought *way* harder about certain standard problems and their
solutions often take into account many of the gotchas that I'd miss.

As to the "method of learning" thought -- I'm open. Reference manuals,
tutorials, whatever. Ideally there'd be a super-experienced,
super-bright coworker (Yoda) to tutor me personally, but alas...

The crux of the questioning was more looking for folks to say "here's
the minimal set of things ya gotta learn to do what you wish and here's
where you can learn 'em" I realize that my rather shotgun approach in
the first posting leaves open to question what it is that I wish to do
-- but that's sort of the point. The technologies seem to be
far-reaching, scattered, and all inter-related.

My progression went something like
- hey, Eclipse seems like it might be helpful
- lookee here, it'll even (maybe) make GUI development a bit easier
- golly I've never done "proper" versioning, that might be handy..

Then, more to the point:
- hey, this JDBC/relational database thing is mostly tedious work that
could be automated.
- hey, this JDBC/relational database thing keeps biting me with
subtleties that take forever to figure out.
- there's a thing called Hibernate (or JDO, or J2EE CMP, or....) that
takes care of some of this.
- wow, there's even a Hibernate plug-in (several actually) that
integrates it to my new-found development environment (Eclipse).
Wonder how? Wonder which one to use?
- To use this one (Hibernate Synchronizer), I gotta either *still* do
the hard database mapping or I gotta learn/use XDoclet.

Basically *every* reference one finds down the open-source technology
path points to five other references. I'd really like someone to say
"go get these three packages and read these three reference manuals --
forget about those others"

So, any takers?

thanx,

-don.
 
D

dexter

Thanks for the input. Valid points all.

My motivation comes from two related drives: 1) better productivity,
and 2) starting to do things in a "more standard" way. The rationale
for (2) being that it's likely that folks in the open source community
have thought *way* harder about certain standard problems and their
solutions often take into account many of the gotchas that I'd miss.

As to the "method of learning" thought -- I'm open. Reference manuals,
tutorials, whatever. Ideally there'd be a super-experienced,
super-bright coworker (Yoda) to tutor me personally, but alas...

The crux of the questioning was more looking for folks to say "here's
the minimal set of things ya gotta learn to do what you wish and here's
where you can learn 'em" I realize that my rather shotgun approach in
the first posting leaves open to question what it is that I wish to do
-- but that's sort of the point. The technologies seem to be
far-reaching, scattered, and all inter-related.

My progression went something like
- hey, Eclipse seems like it might be helpful
- lookee here, it'll even (maybe) make GUI development a bit easier
- golly I've never done "proper" versioning, that might be handy..

Then, more to the point:
- hey, this JDBC/relational database thing is mostly tedious work that
could be automated.
- hey, this JDBC/relational database thing keeps biting me with
subtleties that take forever to figure out.
- there's a thing called Hibernate (or JDO, or J2EE CMP, or....) that
takes care of some of this.
- wow, there's even a Hibernate plug-in (several actually) that
integrates it to my new-found development environment (Eclipse).
Wonder how? Wonder which one to use?
- To use this one (Hibernate Synchronizer), I gotta either *still* do
the hard database mapping or I gotta learn/use XDoclet.

Basically *every* reference one finds down the open-source technology
path points to five other references. I'd really like someone to say
"go get these three packages and read these three reference manuals --
forget about those others"

So, any takers?

thanx,

-don.
 
F

Frank

and handle versioning through cvs
(https://www.cvshome.org/).

Sounds like you're on the right track, lots of sensible tech listed here.

I'd go with subversion for version control, though. It's a 'better cvs',
superior from a devs point of view, and also a breeze to admin, so less
chance of something going awry.

You may also want to consider some kind of testing framework. JUnit
seems ubiquitous these days.
 
R

Rhino

Thanks for the input. Valid points all.

My motivation comes from two related drives: 1) better productivity,
and 2) starting to do things in a "more standard" way. The rationale
for (2) being that it's likely that folks in the open source community
have thought *way* harder about certain standard problems and their
solutions often take into account many of the gotchas that I'd miss.

As to the "method of learning" thought -- I'm open. Reference manuals,
tutorials, whatever. Ideally there'd be a super-experienced,
super-bright coworker (Yoda) to tutor me personally, but alas...
I sense one other qualification that Yoda would have to satisfy: free. ;-)
Otherwise, you could hire someone to tutor you. I assume that is not an
option for you.
The crux of the questioning was more looking for folks to say "here's
the minimal set of things ya gotta learn to do what you wish and here's
where you can learn 'em" I realize that my rather shotgun approach in
the first posting leaves open to question what it is that I wish to do
-- but that's sort of the point. The technologies seem to be
far-reaching, scattered, and all inter-related.

My progression went something like
- hey, Eclipse seems like it might be helpful
- lookee here, it'll even (maybe) make GUI development a bit easier
- golly I've never done "proper" versioning, that might be handy..
I think Eclipse is great. I started out writing Java code with nothing but
an editor (Programmer's File Editor) and a command line. I'm happy to say
that I can still work that way but I find it more productive to use an IDE.
I used VisualAge Java for a while but found that its Java support was always
2 versions behind the version of Java I wanted to run. For example, when I
wanted to run Java 1.3, VAJ was only supporting Java 1.1.8 with 1.3 support
not expected for months. When I finally got fed up with that, I started
looking around and discovered Eclipse, which didn't have that problem. After
a few hours fooling around trying to figure out how to do basic stuff with
it, I found that I could develop more quickly. If I try to develop with a
basic editor again, I immediately miss the colour-coding of my code and the
quick refactoring (renaming) that I can do in Eclipse to name only the first
of several benefits that Eclipse gives. But I'm not suggesting that Eclipse
is the only good IDE out there. I used JBuilder on a project once and found
it pretty decent. I've heard a lot of good things said about NetBeans,
though I've never used it.

I think you probably should get an IDE but you should probably not lock onto
Eclipse before the fact. Give it a try with a simple project and see if the
benefits are worth the effort of learning Eclipse. If they aren't, try some
of the other IDEs until you find one you like. You could conceivably find
that you prefer vi and your command line, although I'd be suprised if that
was the case.
Then, more to the point:
- hey, this JDBC/relational database thing is mostly tedious work that
could be automated.
- hey, this JDBC/relational database thing keeps biting me with
subtleties that take forever to figure out.

I have to admit I'm curious about your JDBC hassles. Maybe it's because I'm
a database guy but I've never found JDBC tedious or troublesome at all. I
was already fluent in SQL when I read a Java/DB2 course (so that I could
teach it a few weeks later!!) and found that the examples and labs on the
course were straightforward enough to get the job done pretty painlessly. A
couple of weeks to reread the lecture notes a couple of times and doing the
course labs a couple of times each and I was pretty functional with JDBC.

In my experience, once I had examples of the major things you do with a
database, I just used those examples as templates for later projects. For
example, once I'd written the code that would connect to the database and
login, I just used pretty much the same code each time. Ditto with executing
a SELECT and processing the result set or executing an INSERT and verifying
that it had worked. And so on.

What problems are you having?

I can't say whether Hibernate would solve your problems but I might be able
to suggest some kind of solution....
 
M

monroeds

I code with vi and build with hand-made scripts. I handle versioning
with hand-made scripts. I use no GUI builder and write JDBC to handle
persistence.

As an old hand using vi, my recommendation is to abandon it relative to
Java.

Java is complex and you inherit methods and data that aren't
immediately obvious.

I suggest http://www.netbeans.org as a potential tool. It takes some
time to learn, but I found it worthwhile.
 
D

dexter

The mundane problems are with simply writing out the SQL queries to
include the JOIN clause(s) and not have any typos. Typos show up at
runtime and the error reported only gives you the line of the JDBC
call, not the particular SQL bit in question. This is tedious and
annoying, but by itself probably wouldn't force me to seek learning. A
similar problem is that with "standard" SQL there isn't an
INSERT_OR_UPDATE, and the format for said commands differs so one must
do a SELECT followed by an if (exists) UPDATE else INSERT. Effectively
writing three statements to perform one task. If there are many items
in your object graph that could be inserted/updated, the tedium (and
typos) increases.

The real problem though is worrying about persistence of object graphs.
If I have a persistent object that has a collection of objects, then
the UPDATE statement (or really, the INSERT_OR_UPDATE bit) for the main
object needs to check each of the items in the collection to see if
they've changed (do an UPDATE), been deleted (do a DELETE), or been
added (do an INSERT). Suppose the relationship is bidirectional.
Suppose the collection is ordered (a List). One needs to pay close
attention to what the book "Hibernate In Action" terms "the scope of
object identity" -- what does it mean to say "this object has already
been saved, but has changed"? It implies you need your code to
maintain database keys which it shouldn't have to do.

All of these things end up making me have to think too hard about stuff
that the folks in relational db land have understood for decades. I
*believe* that Hibernate in particular has been able to shield the
developer from much of this. We work with objects. The
object/relational mapping problem is non-trivial and has been thought
about and implemented by folk with more time (and likely bigger brains)
than me -- and they've put their stuff out there for any to use....just
wish I knew how to take full advantage of it.

-don.
 
R

Rhino

The mundane problems are with simply writing out the SQL queries to
include the JOIN clause(s) and not have any typos. Typos show up at
runtime and the error reported only gives you the line of the JDBC
call, not the particular SQL bit in question.

I don't know what relational database you're using but the two that I use,
DB2 and MySQL, both have ways to run SQL from the command line and from
simple scripts. That gives you an excellent opportunity to experiment with
SQL without having to write programs. If I were you, I would make a point of
developing all your SQL in either the command line or the simple scripts;
play with it there until it is giving you exactly what you want. Of course,
you should normally be going against small test tables when you're doing
that ;-) When you've got the SQL working to your satisfaction, all you need
to do is drop it into your program, typically as a single String, via cut
and paste so that you don't change the SQL. At that point, your statements
should work correctly in the context of your program and you shouldn't have
as many of those tedious problems.
This is tedious and
annoying, but by itself probably wouldn't force me to seek learning. A
similar problem is that with "standard" SQL there isn't an
INSERT_OR_UPDATE, and the format for said commands differs so one must
do a SELECT followed by an if (exists) UPDATE else INSERT. Effectively
writing three statements to perform one task. If there are many items
in your object graph that could be inserted/updated, the tedium (and
typos) increases.
As for the INSERT_OR_UPDATE problem, I don't have a magic bullet for that.
However, this strikes me as a problem that you really only have to solve
once; then all future occurrences of the problem are really just minor
variations. If you write a program that goes against a small table and has
to decide if it needs to insert or update, then do the appropriate thing,
you will have a solid template for all future problems like it. At that
point, it should just be a matter of repeating code. For example, if the
play table that you used has three columns but the "real" table has 50
columns, you have the same basic structure to your program as in the
template but just add 47 more columns to your statements; a bit repetitive
but not difficult so it shouldn't introduce many errors. The errors that it
does introduce are mostly typos like mispelt column names and an IDE like
Eclipse, which compiles constantly, will tell you about those typos as soon
as you start the next line, maybe sooner. That should make coding of those
methods dead easy. The hard part of the code though, where you figure out if
the row already exists or not and then branch into either an INSERT or
UPDATE will already be in your template, along with the code that gets the
connection and decides whether to commit or rollback, as well as whatever
error handling you do.
The real problem though is worrying about persistence of object graphs.
If I have a persistent object that has a collection of objects, then
the UPDATE statement (or really, the INSERT_OR_UPDATE bit) for the main
object needs to check each of the items in the collection to see if
they've changed (do an UPDATE), been deleted (do a DELETE), or been
added (do an INSERT).

Are we talking about batch processing here, where you get some kind of
transaction file like this?

Action Key Details
------- ---- --------
Add 1 name=Jones, title=clerk, salary=20000
Delete 2 -
Change 3 new_salary=25000

I'm a little surprised to see processing like this these days; it's a bit
"old school". Many systems these days seem to be almost entirely online; an
HR person adds a new employee online with an "add one employee" transaction
as soon as the person gets hired rather than batching up requests that run
that night or weekend. But I'm sure some of this still goes on ;-)
Suppose the relationship is bidirectional.

I'm not sure what relationship you mean; I definitely don't know what you
mean by 'bidirectional' in this context.
Suppose the collection is ordered (a List).

What collection are we talking about? The collection of batch transactions?
If so, I assume the transaction sequence is the order of the records in the
transaction file, which were presumably added in the desired sequence. That
means it shouldn't be an issue for you unless the transactions were added in
a sequence that is problematical for you; maybe your program needs to finish
all adds before doing deletes for some reason.
One needs to pay close
attention to what the book "Hibernate In Action" terms "the scope of
object identity" -- what does it mean to say "this object has already
been saved, but has changed"?

As a relational database guy, that phrasing conjures up the word
"concurrency" for me; you need to make sure that you're not hammering
someone else's update before it has been committed. But that is usually
handled via the database's lock manager; before a row can be changed, it has
to be locked and, between the time that the lock is obtained and the update
is committed, only the updater can see it. That is typically handled by the
isolation level of the program and the lock manager of the database. The
developer of the program chooses the isolation level, which is typically an
easy and obvious decision, and the Lock Manager handles all the locking;
your application rarely has anything to do with locking in any direct way,
although it may acquire locks itself in some special cases. But normally
this isn't a big programming issue.
It implies you need your code to
maintain database keys which it shouldn't have to do.
I'm not sure what you mean by maintaining database keys here.
All of these things end up making me have to think too hard about stuff
that the folks in relational db land have understood for decades. I
*believe* that Hibernate in particular has been able to shield the
developer from much of this. We work with objects. The
object/relational mapping problem is non-trivial and has been thought
about and implemented by folk with more time (and likely bigger brains)
than me -- and they've put their stuff out there for any to use....just
wish I knew how to take full advantage of it.
At this point, I can't contribute much to the conversation since I don't
know what Hibernate does. But it sounds to me as if this is the biggest
issue you have so I'd say it should be a high priority. Ant is handy and
useful but it isn't going to give you a lot of leverage on the problems
you've described. I'd put Ant lower on the priority list and think about
learning it when you have Hibernate (or maybe Eclipse and Hibernate!) under
your belt. [For what it's worth, I haven't found a very good Ant tutorial
yet. The manual is passable as a reference but it is not terribly good at
teaching you how to write Ant builds. Maybe if you leave Ant for a few
months, someone will have written a GOOD Ant tutorial in the meantime ;-)]

Hmm. It occurs to me that Hibernate advocates must have some demos of what
Hibernate does and how easy it is to use. They might have been developed
either to help market Hibernate or as part of training materials for
Hibernate newbies. If you could track down some demos that show how it is
used to do whatever it does, you should get a pretty quick grasp on what it
can do and how useful that would be to you. You'll also get an idea about
how to use it, which would make a dent in the training you want to do ;-)
(You may even learn that it is doing something that you can do almost as
easily some other way and therefore avoid having to get it and learn it.) If
I were you, I'd do a Google search on "Hibernate demo" and have a look at
what you find....

Some of the better GUI-based products these days are almost entirely
intuitive to learn so you may find that a couple of hours is all you need to
be comfortable with Hibernate. I know that I did not need very long to be
functional in Eclipse; a few hours was enough.

Rhino
 
N

none

I started like you a bare simple editor, command line tools and should I
added hated IDEs at first, reason being I found they are less
productive. At least ones I tried couple years ago (VisualAge for Java
and JBuilder).
Anyway, at my current job I was exposed to Eclipse and like it very
much. A real *IDE* which offer a large number of plugin for almost any
thing you want to do, write UML specs, design DB schema, use CVS, want
integrated debugging with Servlet/JSP containers to name few.

I also learned SQL first and Java later which resulted in a preference
to use simple JDBC. I always felt JDBC allows you more control on actual
transactions and does result in some (if done properly) performance
boost. However, in a team environment you find some people in team are
not familiar or comfortable with SQL hence simple JDBC causes/poses
problems. Especially if there are chances of leavening *inconsistent
data* especially if object graph is non-trivial with collections. When
my manger asked to move to Hibernate I was a little skeptical. But now,
I find it almost as flexible and strong as simple JDBC in terms of DB
manipulation. That said, there are some points you may have to consider
on per project basis, mainly regarding performance.

As for as learning is concerned, I found Eclipse to be intuitive and
never read any reference/manual just for the purpose of learning.
However, there were times when I need to figure out *how can I do that
....* and for that you can find many on line article. Hibernate is
different story, I think "Hibernate in Action" is a good resource.

That said I think there are a number of other interesting technologies
out there as well. Eclipse+Hibernate combo is just a small subset for a
small problem domain.


Haroon
 
D

dexter

Thanks for the input folks.

At this point, Eclipse is "sold". The time it has already saved in
renaming packages has more than made up for the minimal learning curve.
I slightly miss the vi (actually gvim which is really slick - go check
it out) commands, but as I say, I'm sold overall.

Thus the conversation really turns to how to fit Hibernate into
Eclipse. Again, my problem statement is that I naturally work with
objects and object graphs and would prefer to spend most of my
development effort in this domain. I would like as much as possible to
have mapping and schema handled by the tool. It *seems* to me that the
"natural" mode for Hibernate is to start with the mapping and use the
tools to generate Java and schema. This is still better than starting
with a relational model.

The learning required for these technologies is what I'm confused
about. What exactly do I need to learn? I have a couple of Hibernate
books (the "in Action" is one of them and is, so far, quite good). The
API seems reasonable and not too intimidating. If I were still a
vi/JDBC coder, I would simply add Hibernate API as a tool and
incrementally move forward. But, now that I'm a full-fledged Eclipse
user and committed to focusing on the object model, I'd like to (1)
integrate Hibernate into Eclipse (via any of the afore-mentioned
plug-ins or others), and (2) try to work from the object side of ORM.

Online docs for the plug-ins to solve (1) seem weak. It's hard to tell
which plug-in does what, and what the advantages/disadvantages of each
might be. (2) seems to imply, from my reading, a need for XDoclet or
some other Attribute-Oriented solution to bury the necessary hibernate
tags into the code. Once again, the docs I've found seem weak. More
to the point, as I've mentioned, each new link leads to five others and
their associated technology requirements...It just gets out of hand
quickly. My hope is for someone here to point the way through the fog
and say "here's how to integrate Hibernate" or perhaps "don't bother
integrating Hibernate, use this basic config file and modify as
needed", etc.

Side notes:
Rhino - No, not batch processing. The issue is this: Suppose you have
a complex object graph -- One Root has a List (ordered collection) of
Child(ren). The Root is pulled from the database and passed to a
client application "across the wire". The user interacts with the
object graph by adding/deleting/modifying elements in the List
....perhaps even creating new Root nodes. The user finishes
modifications 'till the object graph is as he wishes it to be, then
sends it back "across the wire" where the server is to persist it.
What's the algorithm? Query the db for each Root node to see if it
already exists. If not, perform an INSERT - otherwise an UPDATE,
DELETE it from the db if it previoulsy existed and the user removed it.
What does it mean to query the db to see if it already exists? -- It
must be that the object maintains knowledge of its primary key in the
db (which is a wart on the object model). Then for each element of the
List, we must determine if the db already contained it (do an UPDATE if
the state has been changed by the user, otherwise do nothing), or it's
been added by the user (do an INSERT). Elements in the List that the
user deleted must be deleted from the db (but what if a Child might be
"owned" by multiple Roots? -- then it's only deleted if it's not
referenced by any other Roots -- more SELECT statements). Since the
collection is an ordered list (and SQL has no direct concept of such),
how do we now update the additional column "SEQUENCE_NUMBER" to keep
the List ordered properly?

This is a pretty simple object graph and it's already pretty hard at
the db side. How does one handle inheritence? How does one address
differing levels of granularity (not "one table = one object")? I have
an idea how to solve each of these issues, but my point is that if with
my limited db experience and bit of reading, it's likely that I've not
even considered some other gotchas. The highly paid db-gurus have
their own user groups where they debate the finer points of relational
theory ad infinitum. I *really* don't want to have to be that good to
add persistence to my applications. ORM (object/relational mapping) is
a theory unto its own and Hibernate is but one (highly touted)
implementation of it.

Haroon - I'm interested in what you call "other interesting
technologies out there". I know there's a ton, but what do you find
fundamental to your work?

-don.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top