Re: searching for yoda - a developer's tale
From: Rhino (rhino1_at_NOSPAM.sympatico.ca)
Date: 02/24/05
- Next message: klynn47_at_comcast.net: "Re: Exec with args + env in Java?"
- Previous message: chicagoandy_at_hotmail.com: "Re: JAXB: Nested Type hides an Enclosing Type."
- In reply to: dexter_at_uwm.edu: "Re: searching for yoda - a developer's tale"
- Next in thread: none: "Re: searching for yoda - a developer's tale"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 24 Feb 2005 15:39:39 -0500
<dexter@uwm.edu> wrote in message
news:1109258740.630796.267770@f14g2000cwb.googlegroups.com...
> 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
- Next message: klynn47_at_comcast.net: "Re: Exec with args + env in Java?"
- Previous message: chicagoandy_at_hotmail.com: "Re: JAXB: Nested Type hides an Enclosing Type."
- In reply to: dexter_at_uwm.edu: "Re: searching for yoda - a developer's tale"
- Next in thread: none: "Re: searching for yoda - a developer's tale"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
