This week's book giveaway is in the General Computing forum.
We're giving away four copies of Emmy in the Key of Code and have Aimee Lucido on-line!
See this thread for details.
Win a copy of Emmy in the Key of Code this week in the General Computing forum!

Loren Rosen

Ranch Hand
+ Follow
since Feb 12, 2003
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Loren Rosen

Supposedly Apple's laptop market share (in the U.S. at least) is more like 12% (as compared to the 5% overall market share).
12 years ago
The Configuration object reads the hibernate properties and the hibernate mappings files and creates the internal data structures about them. Usually your application will create just one Configuration, unless you're using multiple databases with different schemas.

The SessionFactory creates sessions. It also creates some things that are used collectively by the sessions it creates, such as a database connection pool and the second-level cache. Usually you will have one SessionFactory per Configuration. Exceptions might be if you have multiple databases using the same schema, or if you need to connect to the same database via different accounts (perhaps for security reasons).

Finally, a Session holds a database connection and its associated transaction and first-level cache.
You should run EXPLAIN on the query. See the PostgreSQL docs. If you have trouble interpreting the results post them here and I'll look at them.

(But yes, most likely you'll need some sort of index to make the query faster.)
Do the following in Eclipse:
Help -> Welcome -> Tutorials -> Create a "Hello, World" plugin
To put this slightly differently, it depends on the ORM tool and the details of your model, but it's quite possible that you could get the business rule code in the middle tier to execute the same queries as does the business rule stored procedure. The stored procedure would be modestly more efficient but the difference might be enough to trump other engineering considerations.
With most ORM tools there doesn't have to be a 1-to-1 relationship between database tables and Java classes.

Also, with most tools you can fetch data from multiple tables in a single request (that is, do database joins). The potentially big win with a stored procedure is that you may save the cost of transferring the data between the database server and the application.
IIRC Hibernate uses Log4j. You should be able to configure log4j to send different messages to different log files.

Alternatively, you could post process the log file to extract just the messages you're interested it. This shouldn't be too hard with the usual Unix tools like grep, sed, awk, etc., or perl if necessary. I'm less familiar with simple text processing on Windows but something must be available.
The usual approach is to use your DBMS' "explain" facility. This will tell you what algorithm(s) the database will use to execute the query.
A couple of things that might be going on.

classpaths have elements separated by colons ( the : character). But in the command line example you have
java -cp .
instead of
java -cp .

Second, check the structure of your jar file, using 'jar t'. what often happens is that the class files are there in the jar but path to it inside the jar isn't what it should be.
14 years ago
I haven't had any such problems with Eclipse 3.0.x on OSX 10.3. I assume you've already tried 3.0.2 which ought to be more stable than one of the 3.1 releases.

Can you run other Java programs? I'd like to rule out the possibility that your Java installation is somehow broken.
Spring and Struts, etc. are J2EE compatible in the sense that they utilize parts of J2EE, such as Servlets. You can use them in a J2EE Application Server fairly easily. But they're not J2EE compliant in that they're not implementations of any of the official J2EE specs.
It's usually better to do one big query than to, in effect, do joins in your application code. But a complicated, slow query like this one will take some work on your part to optimize. You'll need to add the right indexes, and you may need to prod the database a bit to get it to choose the best join order.
J2EE encompasses a bunch of different technologies (or, more precisely, specifications for technologies), for all the different layers of an application. It includes servlets, JDBC, JSP, EJB, JMS, etc. There's also an overall notion of how these pieces should work together. Sun promotes the idea that you have to take the entire package, all-or-nothing. But this isn't true: some people use everything but substitute a different view technology for JSP. On other hand, most people using Spring still use JDBC and Servlets.

In principle since various alternatives have to solve the same problems, there will be some ideas that carry over. But in many cases the details a different enough that transisitioning from one to the next won't be that much easier than started from scratch, at least the first time you do it. (After you've done it a few times, it gets easier, just like learning your fourth foreign language is easier than learning your second.)

So what to learn first? I think some of the J2EE alternatives like Hibernate and Spring are simpler and therefore probably easier to learn. On the other hand there is less choice for books and other learning material.
If you expect to read this data many more times that you update it, then overall denormalizing it is more time efficient. However, there's more to life than just time efficiency. The demormalized solution uses more space. It's harder to maintain, since it will require an update trigger. It's not clear that the time gain is worth these costs.

The usual development approach is to keep the data normalized, and only denormalize if you encounter a performance problem. In other words, to apply the usual advice about avoiding permature optimization.

If you do decide you want this kind of denormalization, see if your database supports materialized views. This might entail less maintainence than a trigger.