Slashdot Mirror

In the Java world ORMs are "standard", the most common used is http://hibernate.org/

There is a .NET port NHibernate or N-Hibernate, no idea how established its usage is: http://nhibernate.info/

I personally fool around with OO databases, especially OrientDB. http://www.orientechnologies.c... Technically it is a graph database, but via the JavaAPI you can simply map POJOs into the DB. It is a very very fast database with replication and cloud support (extremely huge graphs are possible)

I use Java as my language of choice (because I know it and there are tons of libraries available.)

For web sites that are use by people, I use Apache Tapestry 5 as the web framework. It's very easy to use, integrates with Hibernate, is very fast and makes me very productive. I find that I can write nice looking pages that work well in a very short amount of time. I end up writing very little actual code, so maintenance is easy. Live class reloading is a major plus, I just edit my page or Java class, hit save and the changes are ready to be used in my browser.

However, there are many other Java web frameworks to chose from based on what you like best. Java is a bit bloated, but it's pretty fast and stable. And there are libraries for almost anything. (I generate PDFs, for example, using iText and everything works very well together.)

I use Eclipse for my IDE, which while it could be faster and less bloated, seems to work pretty well.

If you want to focus entirely on web services (e.g. SOAP or REST), then there are easier solutions for that in the Java world. (I use JAXB annotations with Jersey for REST services.) For SOAP I'd use Apache CXF based on what I've read. You can integrate both of these with Tapestry and Hibernate to create a cohesive web platform.

Sigh... It waould be better to ban your developers off SQL and into an abstraction layer that puts the queries together behind the scenes and hire a competent developer to develop that.

In the Java world they already do. It's called Hibernate (or NHibernate for .NET). It does exactly what you describe.

The only people that should be mucking about in SQL are DBAs that...

• Know what the fuck they're doing
• Have a good fucking reason to use it (stored procedures, custom reports, business functions, etc.)

I suggest using NHibernate, since you get to be fully OO and it generates parametrized SQL for safety. (You can use data binding with custom objects since .NET 2.0.) Then if you have a data object with a field containing HTML, you can deal with encoding at the object level...

public virtual string thisIsPotentiallyDangerousUserText
{
get { return someHtmlString.Escape(); }
set { someHtmlString = value.Escape(); }
}

That way you can be absolutely sure it is checked both going into and coming out of the database.

a product that only supports that db, or developers who aren't particularly familiar with what relational databases are supposed to be like

But then why bother with MySQL at all, when you can get use SQLite? It's fast-as-hell, 99% SQL92-complete, works with application servers (JDBC driver), doesn't require any DB services running in the background, etc.

(For J2EE developers...) You can even hook it up to your app with Hibernate. Excellent not just for small websites, but also good for running "demo apps" with dummy data (since you don't have to install a database server).

I've heard great things about Lucene (guy at the company I used to work for swears by it, he used it for anything from searching B2B stores to biological indexing). Both Hibernate and Spring have support for this library.

I'm looking into adding search on my site so I should probably check it out. There's a new "In Action" book out for using the Hibernate Lucene add-on -- I might have to pick that up.

JSF, RichFaces, Hibernate, MySQL, developed on NetBeans and served by Apache TomCat on CentOS for a state government contract.

We have to train ourselves, but that's half the fun.

The other half will be when we pull the plug on one legacy Oracle database with a per CPU cycle license the state is paying an obscene amount of money for.

Unless you like being stuck with Java!

Both are available in .NET versions, if you prefer.

AFAIK, you can access a DB via both JDBC and Hibernate. Just do most of the job with the frameworks and just the little bit that isn't supported use plain JDBC.

Actually, Hibernate gives you a range of options. You can:

• Construct SQL queries and let Hibernate map the results into objects.
• Construct SQL queries and get the results as arrays of scalars.
• Bypass Hibernate completely and just operate on the raw JDBC connection. Just make sure you flush the session first if you're querying DB state that the session might have modified recently, and clear the session cache if your JDBC calls might have modified data that the session has cached.

Hibernate is successful in large part because it gives you a lot of options, so you can adapt it to your needs.

AFAIK, you can access a DB via both JDBC and Hibernate. Just do most of the job with the frameworks and just the little bit that isn't supported use plain JDBC.

Actually, Hibernate gives you a range of options. You can:

• Construct SQL queries and let Hibernate map the results into objects.
• Construct SQL queries and get the results as arrays of scalars.
• Bypass Hibernate completely and just operate on the raw JDBC connection. Just make sure you flush the session first if you're querying DB state that the session might have modified recently, and clear the session cache if your JDBC calls might have modified data that the session has cached.

Hibernate is successful in large part because it gives you a lot of options, so you can adapt it to your needs.

AFAIK, you can access a DB via both JDBC and Hibernate. Just do most of the job with the frameworks and just the little bit that isn't supported use plain JDBC.

Actually, Hibernate gives you a range of options. You can:

• Construct SQL queries and let Hibernate map the results into objects.
• Construct SQL queries and get the results as arrays of scalars.
• Bypass Hibernate completely and just operate on the raw JDBC connection. Just make sure you flush the session first if you're querying DB state that the session might have modified recently, and clear the session cache if your JDBC calls might have modified data that the session has cached.

Hibernate is successful in large part because it gives you a lot of options, so you can adapt it to your needs.

AFAIK, you can access a DB via both JDBC and Hibernate. Just do most of the job with the frameworks and just the little bit that isn't supported use plain JDBC.

Actually, Hibernate gives you a range of options. You can:

• Construct SQL queries and let Hibernate map the results into objects.
• Construct SQL queries and get the results as arrays of scalars.
• Bypass Hibernate completely and just operate on the raw JDBC connection. Just make sure you flush the session first if you're querying DB state that the session might have modified recently, and clear the session cache if your JDBC calls might have modified data that the session has cached.

Hibernate is successful in large part because it gives you a lot of options, so you can adapt it to your needs.

I was under the impression the transaction support in Hibernate was more than sufficient for most purposes. I come from a .Net background so most of my experience is using the NHibernate port with the Diamond Binding active record implementation. In this, using transactions is as simple as using(new TransactionScope()) { ... }.

Any complex queries can be handled using HQL (including aggregates, etc, if you are feeling really manly), and if you really need you can get the connection and use ADO (similar to JDBC) for hitting sprocs/whatever, in the same transaction.

So I agree with parent, I think OP needs to read up on his framework more. Hibernate can be fairly intimidating, but this makes it quite flexible (difficult for clustering though, but I guess theres always Shards). The main reason we went with Diamond Binding is because it simplifys things down a fair bit (and gets rid of those pesky mapping files) which helps the junior devs a fair bit.

Considering that Java has been (probably) the most used language for a while, you get a lot of crap. So, here's my "crap filter" list of what you should learn to really hop into the JVM ecosystem.

Books:

  1. Effective Java, 2nd edition, by Josh Bloch

This covers most of the twists and turns of the basics that an experienced programmer would need. I wouldn't worry about getting a simpler book.

  2. Java Concurrency in Practice

Understanding the JVM model of concurrency is important, and this is the only guide that had a pretty in-depth look into the subject. The Sun documentation absolutely sucks at covering concurrency.

APIs

  1. Guice http://code.google.com/p/google-guice/

Dependency injection is the most recent thing that makes Java a very powerful language for building large appications. And Guice is by far the best implementation of DI. (Yeah, you could learn Spring, but I just don't care for it.)

  2. Hibernate http://hibernate.org/

I hate Hibernate. But it basically set the standard for EJB3. If you know Hibernate, it's not a very hard road to learn all the other "enterprise" crap.

On the other hand, any substantial server-based solution probably uses a ORM solution like Hibernate.

  3. Apache's Commons http://commons.apache.org/ and Jakarta http://jakarta.apache.org/

There is a ton of projects under the Jakarta umbrella these days. The first one to try out is the commons-lang libraries, which provide very easy to use toString. equals, and hashCode implementations that are 'good enough' 99% of the time. Why do you need those? Read Effective Java. :)

Interesting stuff:

  1. Hadoop http://hadoop.apache.org/

Hadoop is an open-source implementation of Google's MapReduce idea.

  2. Scala http://scala-lang.org/

Scala is my favorite "non-Java" JVM language by far. For me, the scala interpreter is how I learn APIs. In fact, most of my new code is in Scala, not Java.

  3. Groovy, JRuby

Just some more used non-Java JVM languages. I've used JRuby a bit, but have moved on to Scala. It's still a significant project, however.

  4. Web application frameworks: Wicket http://wicket.apache.org/ + Databinder http://databinder.net/

Wicket is the simplest page-based Web framework I've ever used. I just find it easier to navigate than Rails. If you really want an ORM-based solution, go for the Databinder extensions. Databinder will get you coding in a couple of minutes.

  5. Restlet http://restlet.org/

We have several different clusters, and a bunch of machines that need to transfer data around. I learned how to set up a restlet server that was integrated with Guice in a couple of hours, and now, have a very easy means to script together many different servers.

Up until recently I'd had a similar opinion. Then I started work on a new project and began noticing all these interesting technologies.

Some exciting technology is being developed using Java. Check the trove.

If he was in hibernation then he would know it wasn't.

Hibernate has its limitations. I seem to have hit them a few times. Hibernate is great for doing simple things, but if you use any vendor specific features or really complex SQL, you may find yourself falling back to JDBC.

You are completely wrong about drop/delete in HQL. Instead of quoting references you don't have, here's the result of a quick Google search.

http://www.hibernate.org/hib_docs/reference/en/html/batch.html

Your ignorance tells me you have very simple database needs. That's the siutation in which Hibernate will shine.

However, Hibernate can also be rather complex and unintuitive to control. The XML you have to write includes subtle options which need to be set correctly to get expected behaviour. It's very very easy to change an option and completely break a system.

Your smug attitude is awful. You've found a framework that meets your specific needs, but other coders have other needs that aren't met by your pet framework. By the way, I hope you're being paid to plug it, since otherwise you've been brainwashed.

Now, you can use HQL which is a bastardized version of SQL to generate similar things but, again, I think that you can't drop/delete in it (could be wrong, rarely use it).

You know, as an incompetent Java developer, I will take the time to explain why none of my web applications suffered from this.

I use Hibernate. I use it with Java, although I know it's now available for .NET.

A feature of Hibernate (aside from some efficient connection pooling and resource management like caching) is that you have to actually call a delete method to delete a row. Something like HibernateSession.delete(myObject); would have to be done. And while this might sound annoying or ruin some tools that are used to generate SQL statements, it protects me time and time again. Now, you can use HQL which is a bastardized version of SQL to generate similar things but, again, I think that you can't drop/delete in it (could be wrong, rarely use it).

Try passing part of an SQL string into an object property and then merge/save it into the HibernateSession. Doesn't do the SQL injection stuff the bad guys want it to. Of course, I still use regular expression common utilities to validate the input, but assuming you didn't do that ...

So why don't other people use Hibernate? Am I missing something about it that's bad?

This really shouldn't be a function of the RDBMS. If you wanted such a thing writing a driver wrapper for any RDBMS should be fairly easy. However, coding your database mappings without locking down your feature set is kinda useless. What's more interesting is creating scripts to generate your database schema from your code. It's been done, see Hibernate.

Interesting. I work at Google, and "shard" is Google-speak for one "partition" of a distributed system. It's also a verb: "shard it" is the usual response when someone has to write a system dealing with large amounts of data. And last year, some Google engineers open-sourced a sharded version of Hibernate (an ORM layer for Java) a year or so ago, and some of the papers on research.google.com talk about this technique too, I think. And on a lighter note, a couple of years ago someone replaced the "Shred-it" signs on some of our shredding bins with "Shard-it" signs.

I don't know what the derivation of Google's "shard" term is, because our internal glossary doesn't have an etymology section and I'm not enough of an old-timer to know the history. I'll have to ask around.

So Google used horizontal partitioning to split load across servers? Wow, that's rocket science. None of us in the database community have thought of doing this before. :-) But, if you want to find some news here, you can. One nice thing that Google did recently was to donate their horizontal partitioning code for Hibernate to the open source community. Hibernate Shards definitely needs a lot of work to get it to the point where it does a lot of stuff that people would want, but, hey, release early and often!

I'm a big fan of http://plone.org/ which is a CMS that sits on top of the http://www.zope.org/ application server. All of which is OSS. I can't speak to OSS CRM but others here have. There are plenty of fantastic server side developer productivity boosting OSS software out there.

• Try http://jakarta.apache.org/ for lots of Java libraries.
• I find http://www.springframework.org/ is a great framework extension for Java.
• I like spring better, but http://www.hibernate.org/ provides an ORM for both Java and .NET developers.
• If you are working in Perl, then http://www.cpan.org/ is the place for you.

When it comes to client side software there is a huge amount of great OSS apps.

• I believe that http://sourceforge.net/projects/ganttproject/ is great for project management.
• I have used http://sourceforge.net/projects/freemind/ for years and know it to be a great mind mapping tool.
• I believe that http://live.gnome.org/Dia/ is a great diagramming tool.
• I'm a big fan of http://www.umlet.com/ and find it to be very useful for creating UML diagrams.
• I switched from sodipodi to http://www.inkscape.org/ which is fantastic for drawing vector images.
• I am also a big fan of http://www.gimp.org/ which is used to draw raster images.

I have used all of these projects for years and would most definitely label them as quality, winner OSS.

One of the first problems which Developers will need to master is Cache-Consistency. We are not being helped very much here. At the moment this is all very level/library specific. All the tricks for, say, elegantly sharing a session in a Hibernate based J2EE webapp are different for synching L3 cache structures between different cores. They are the same Cache-Consistency problem in principle.

Hibernate accomplishes a lot by giving in-code Hints [called AOP for some stupid reason]. These are instructions which are reasonably close in to where the code which deals with that data is located.

What is needed is a lot more consistent frameworks for describing what data should be shared between cores&servers. Some will be a priority and the rest can be fetched later. Similar to marking

register

Describing this data stuff cuts across many levels. Data design, language choice, IDE integration, build tools and then target deployment environments.

It's reading about issues like this that make me love Hibernate, Struts and Tomcat. At least at work. ;-) It's all about the sensible security defaults and maintainability, neither of which are particularly common in PHP development. Seriously. All you PHP fanboys, I don't know if you're just scared of the learning curve or what, but the jump to J2EE is totally worth it for any serious application.

I don't see this making a big difference. Most of the open-source Java software I've seen is aimed at accomplishing a particular task in Java, so the people who would consider using it have already bought in to Java itself. I'm thinking mostly of web development frameworks like Hibernate, Struts, and Webwork. The people using them have already made the decision to do server-side Java; the fact that it's now open-source is nice but not really that big a deal. Maybe I'm biased because I mostly do server-side Java development, and everyone I know who writes that sort of software already uses plenty of open-source libraries.

I got sick of the syntax dialects of every SQL engine, so I started writing my applications using Hibernate and haven't looked back.

I learned HQL (Hibernate Query Language) and just use whatever database is handy at the time.

I usually start with MySQL 5, and then if I need more muscle (Read: the boss wants to spend money), I can switch the entire application to Oracle in about two hours.

You want ACID...? Use J2EE transactions and Hibernate, and never worry about which database you use again.

Check out: Typed DataSets, LINQ and ADO.NET Entities. The last two technologies are under development. In the mean time, how about NHibernate, or ActiveRecord.

It wouldn't make sense for a relational database to do this, so you will always need an abstract layer in between. The ADO.NET API gives you direct access to the relational data, the aforementioned layers will abstract it for you, where LINQ uses new language constructs to try to bring queries in a natural syntax to your programming.

Look into Hibernate. It's an open source OR-mapping tool. I've never used it with .NET, but I've used it with Java and it does a great job of abstracting out all of those SQL queries and lets you just save an object to the database. I think the .NET version is called NHibernate.

It is a full-featured and low-overhead ORM. Go to http://www.hibernate.org and check out the NHibernate link.

Plus, there are several books avilable from, e.g., O'Reilly, Manning.

First of all, Hibernate came after EJB

This is true. I meant that EJB and Hibernate were both attempts to solve the object persistence problem.

either Hibernate nor EJB does any bytecode manipulation or other JVM tricks.

This is incorrect. Hibernate uses CGLIB and ASM to do runtime magic. They explain this in their FAQs. Rails is possible because Ruby gives developers power that Java denies unless you do magic like that.

Second, EJB is very much alive [...], and was designed with a lot of the features of Hibernate in mind. [...] You should really check out the features in Java EE 5. It was designed to make developer's lives easier.

Yes, this is exactly my point. For years, EJBs were hideous to use and bad performers; I made several "enterprise" systems perform 10x better (and, as a bonus, much easier to work on) by ripping out the EJB crap that others put in when EJBs were fashionable. The Hibernate guys showed years and years ago that there was no need to suffer like that, and Sun has finally come around.

This is exactly the sort of good influence open source can have on Sun's cathedral-style, enterprise-bunker view of the world. But both C# and Hibernate show that Sun needs to keep getting their noses rubbed in it before the realize that making developer's lives easier is the primary point of a programming language. Hopefully Rails will give them a kick in their web-framework keister the way that Hibernate's independent success made them realize their persistence sucked.

First of all, Hibernate came after EJB

This is true. I meant that EJB and Hibernate were both attempts to solve the object persistence problem.

either Hibernate nor EJB does any bytecode manipulation or other JVM tricks.

This is incorrect. Hibernate uses CGLIB and ASM to do runtime magic. They explain this in their FAQs. Rails is possible because Ruby gives developers power that Java denies unless you do magic like that.

Second, EJB is very much alive [...], and was designed with a lot of the features of Hibernate in mind. [...] You should really check out the features in Java EE 5. It was designed to make developer's lives easier.

Yes, this is exactly my point. For years, EJBs were hideous to use and bad performers; I made several "enterprise" systems perform 10x better (and, as a bonus, much easier to work on) by ripping out the EJB crap that others put in when EJBs were fashionable. The Hibernate guys showed years and years ago that there was no need to suffer like that, and Sun has finally come around.

This is exactly the sort of good influence open source can have on Sun's cathedral-style, enterprise-bunker view of the world. But both C# and Hibernate show that Sun needs to keep getting their noses rubbed in it before the realize that making developer's lives easier is the primary point of a programming language. Hopefully Rails will give them a kick in their web-framework keister the way that Hibernate's independent success made them realize their persistence sucked.

You know a thing is superhyped when v1.1 is mentioned on slashdot.
Mind you RoR is cool compared to j2EE. Then again, it's allmost as if C is cool when compared to J2EE. J2EE sucks big time for server side web - even the Java Gurus agree on that. End of discussion, no news here.
But RoR isn't the end all of ssi frameworks. Django is at least as good (I'd say better and cleaner than RoR) and Zope has been around since the ninties and still is years ahead of the rest. People with an overview over the technologies generally agree on that. I had a story submission (rejected) on that the other week. Check out the linked webcast, it's a very interessting analysis of a set of technologies and solutions:

|||||
Nasa/JPL Web Framework Shootout

In an educative and entertaining webcast, Sean Kelly, a Nasa/JPL software engineer, goes into the details of a project based comparsion between a set of web application frameworks and servers. Including the much hyped Ruby on Rails and Django. Various Java technologies, Ruby on Rails, Django, TurboGears and Zope are covered. Details and traits of each are mentioned. For people involved with web developement there are not to many suprises though, yet the presentation and Kellys commenting are fun to watch.
In a nutshell: EJB, Hibernate and various other Java flavours fail spectacularly, Zope scores a clear victory with Django, RoR and TurboGears relatively close behind. Development speed, error-gotchas, the need for hand-tweaking and the requirement of handwritten SQL and available documentation go into the measuring. As does an overall tongue-in-check "fun-factor". The details are interessting though. TurboGears 'error-driven' developement gets a positive review, RoRs automated controller generation aswell and Zope gets a complete rundown on it's astounding set of features. In the end long-time Java developer Kelly convinces us that - no matter what we do - we really, positively, don't want to use EJB or Hibernate for this kind of stuff. Very entertaining and informative indeed.
|||||

Just saw your message..


Have you ever done it? It's awkward and you end up hand mapping from a result set. There may or may not be a better way but frankly I find the Hibernate documentation abysmal, the versions of Hibernate aren't backward compatible, and to top it off the mediators on the Hibernate forums tend to tell you to read the documentation if you raise a legimate concern (if they're being polite that day).


Yeah it's easy, just use the {} operator:


Query sqlQuery = sess.createSQLQuery("select {cat.*} from cats {cat}", "cat", Cat.class);
sqlQuery.setMaxResults(50);
List cats = sqlQuery.list();


You've doubled your complexity. You're using 2 different ways of doing everything - from the query language to the actual object mapping.

It can't do everything, I'll take what I can get.

I have to disagree with that one I'm afraid. You just move mapping code into hibernate configs instead, and end up having to debug both.

I don't touch the config files.

I generate them.


You must be using Hibernate 2. Hibernate 3 removes and deprecates the hibernate tools, substituting a very flexible but much less graphical ant based tool, though I believe people are attempting to writing mapping tools on top of that. (Please let me know if I'm wrong on this one. If you're doing this in Hibernate 3 I'd appreciate being pointed to the tool. No sarcasm here.)

Hibernate tools does this for v3: link

It's graphical enough, not like middlegen but it's very nice, does the job. I point it to the DB, restrict tables if I choose, decide if say a BOOL maps to Boolean/boolean, etc. and then, in eclipse, click generate and it generates the POJO files and hibernate mapping documents.

I've got no interest in being cynical and against the grain. Rather I'm totally dishearted by the rubbish that gets pedaled as if it were pure genius. I mean for pity sake move the mappings from strongly typed Java code to XML hell configs then claim to be really configurable and reusable??? Come on, who's actually reused a hibernate mapping for more than one class??? Then they somehow magically claim you don't have to write code, ignoring the XML. This has always just ticked me off.

You don't have to muck with xml files, read the above.


I was at a Spring conference the other day, and the amount of smoke and mirror handwaving rubbish I heard amazed me - more because people took notice of it and thought it was wonderful than for the fact that someone could say it.

As for the rest, I've never dealt with the Hibernate team but I've read enough of their posts that I know I don't want to.

Hibernate is amazing, Gavin, the creator, if you're out there, you are a giant ass wipe.

My latest project has no Hibernate XML files at all which makes me VERY happy. :)

The hibernate tools project does provide eclipse plugins for Hibernate 3/EJB3: http://www.hibernate.org/255.html

Actually you could make this class totally generic by having it query the DB for all the field information. That could even include validation to make sure the input is the right type, length, etc. All the info you need for that is in the DB. The problem is that, unless you're just writing a generic DB table editor app, you generally need unique methods for each table/object.

If you find this kind of thing interesting, it's probably worth checking out some persistance layers like hibernate or (for PHP) Propel

After scanning the doc on LINQ, this is basically just a rip-off of Hibernate for Java. The problem with these highly abstracted APIs is that they mask too much native DB functionality. Unless you can code NATIVE sql, these kind of object abstractions will never be able to displace mid level interfaces like JDBC/ODBC. Even then, there's a whole vendor specific API that's only available in interaces like OCI for Oracle. I'm sure there's more to C# 3.0 than just LINQ, but this feature won't be the java "killer".

• Build Tool - Ant (http://ant.apache.org/)
• Unit Test - JUnit (http://www.junit.org/)
• Application Framework - Spring (http://www.springframework.org/)
• Security Control - Acegi (http://acegisecurity.sourceforge.net/)
• UI Framework - JSF (MyFaces) (http://myfaces.apache.org/)
• J2EE/Web Server - JBoss/Tomcat (http://www.jboss.org/)
• OR Mapping - Hibernate (http://www.hibernate.org/

Now Hibernate, especially with Spring transaction management is much easier to deal with for most cases. And it works very simply, and there's even a native SQL-like object query language called HQL to help. And it writes very efficient SQL queries (I've done a lot of investigation on this on objects backed by tables with tens of millions of rows) to the back end, is entirely DBMS-agnostic, and is apparently the basis for many of EJB 3.0's enhancements over 2.0.

Most J2EE devs don't get much choice on this stuff, but if you do, learn these 2 frameworks. They're even Open Source (and free-as-in-beer) so you can hardly go wrong, really.

HTH

Dan

Well, my personal experience is with hibenate. It might not work quite the same as SQLObject.

hibernate does have a feature that allows you to use direct SQL calls. However, it's definitely no magic bullet for solving every problem. Also, using native SQL seems to be recommended only as a last resort by OO purists and ORM snobs such as myself. The more you add, the more you lose your DB independence.

One simple example of a tricky situation is that I may want data from tables that requires loading 75% of my entire graph. I practically have to load the whole database just to get a few fields. So I have to dig deep into the mapping files & loading strategies. I may optimize these for one view at the expense of another. So, I may have to compromise at times.

To me, it is worth the trade-off. I'm pro-ORM. But, not because it necessarily saves me time. I would still say that trickery, voodoo and a bit of black magic are all required when using an ORM on a complex project.

Hello, If you're interested in an alternative bug tracking tool that is open source, you should check out TrackIt. Not only does it manage bugs, but it also supports features, requirements, test cases, and much more, in addition to any user defined item types. It integrates with Subversion and CVS, as well as preliminary integration with Eclipse. Other features include a Timeline view that is also viewable via RSS, a Listing driven by HQL, Reports driven by SQL, fully customizable lookup lists, project news, a high level summary view, nightly build integration, and user customizable RSS feeds.

Under the hood, it's implemented using Hibernate 3 and the fully AJAX enabled Java web toolkit, Echo2

You're comparing a decent templating engine (Smarty) with crap Java technology (JSPs.) Most modern Java programmers disdain JSPs and use other, better templating technologies. Try using Velocity . Requires no recompiling when you make changes and is a very very easy templating language that provides an amazing amount of power (you literally can drop items into a hashtable of VelocityContexts and then access them by using "$" notation... such as "$user.name") If you want something that will really rock your world, check out JSF or Tapestry (it turns web programming into writing an event-driven application, like desktop apps.)

The problem with most PHP applications is that they don't scale. I don't mean that in a "PHP SUXORS! YOU CAN'T WRITE S$!@ IN IT"... I mean that most PHP applications aren't built with any real caching implementations (like this gallery software, or phpbb, or nuke, etc...) and the PHP frameworks that I looked at don't really provide that functionality.

The stuff availble for Java is just so much more powerful. You have the Hibernate OR mapping package that provides an amazing amount of OR work for you, including the ability to plug in multiple transactional caches, session caches, database connection pools (including the ability to have clustered caches across multiple boxes.) You have complex messaging architectures to talk to and keep multiple machines in sync. You have great web service APIs and great search engines that can be plugged in. Stuff to that degree just doesn't exist for PHP.

It often shocks me to see so many "Enterprise Level" PHP apps released with no caching implementation... you shouldn't see ANY home page hit a database on every hit. (And yes, you can easily avoid stale content by eviction, injection routines.)

So yes, you can definitely write decent stuff in PHP. But for the highly scalable enterprise environment, the libraries and packages that exist for Java and ASP just don't exist.

The other thing I hate about PHP is that there just is no IDE that is of the caliber of Eclipse for PHP (and PHPEclipse just ain't there yet.) A professional IDE allows me to introspect objects, trace stacks, change variables on the fly per hit and control each thread individually. This kind of power makes debugging and performance testing so much easier and more powerful than a PHP app. Good luck trying to seriously profile a PHP app...

So yea, PHP has it's place. It's wonderful for quick one-offs. I just wouldn't want to code a massive user load, transactional, high availability, multiple machine cluster application on it.

If you live in the Java world, the best way to protect yourselves is to have an object to relational layer between your code and the database.
http://www.hibernate.org/ is a neat way (but there are many others). This removes a lot of the ties to the vendor's database so that if MySQL were to do something stupid, your code is safe.
There are most certainly layers like this for other languages - I am not sure it seems hard enough just to keep up with Java.

"If a company wants to run a giant professional website and has money to throw at it, they'll get WebLogic or WebSphere to run it."

Or they'll forego bloated commercial app servers and EJB and go with a lightweight open-source framework. These aren't toys - in fact the EJB 3 standard being developed now is largely based on ideas copied from these frameworks, as well as the Hibernate open-source persistence service.

Would a few slightly better designed stored procedures help? Maybe a tiny bit.

I would look into using hibernate with some sort of caching routine, like ehcache. Don't design a caching routine yourself.

Just doing that would save hundreds of hits to the database.

How about distributed caching (SwarmCache, Tangasol, Memcached)? How about optimistic locking based on timestamps (it is still absent and we needed it BADLY)?

And Ruby's transaction support is very limited, for example it's impossible to detach record from a transaction, save it to session and then reattach this record to a new transaction (with concurrency control based on timestamps/verisons, of course). Hibernate (http://www.hibernate.org/) supports this, BTW.

I guess the answer is "it depends". ;-)

If I'm doing anything half-ways complex in web-to-db, yes I do want OO. I'll choose OO DB access in the form of Hibernate, JDBC, JBoss and EJBs and XDoclet. And I'll build my UI with an MVC-based JSP/Servlet framework, usually home-grown, but maybe using JavaServer Faces or Struts.

In my opinion, this kind of OO sophistication makes building even half-ways complex projects better.

Sam

There is no such animal. There is such a thing as object/relational technology. Some common examples of this are hibernate and EJB. These are not alternatives to relational databases. Rather, they serve to persist objects to and from relational databases. They are built on top of relational databases. They do not replace relational databases.

Alternatives to relational databases are LDAP databases such as openLDAP, OLAP databases such as Hyperion, and XML databases like exist. None of these technologies will replace the relational database. It's more about using the right tool for the job. Relational databases work best with operational data. OLAP works best for planning and forecasting. Think of LDAP as a distributed hierarchical database.

Various relational database products have proprietary extensions that may confuse you into thinking that they are alternatives to relational databases. For example, there are extensions to SQL Server that make them seem to act more like OLAP or XML databases.

Indeed! And companies like M$ seem to build this base of zealots who latch on to every bad idea they come up with to add more poor code to their products and preach it like gospel. It is really obvious why software seems to run slower as the chips run faster: bad software methodologies that somehow miss the major points: 1. the more code you write, the more likeliness for errors and the slower it will run, and 2. write code to be readable so your job, and the jobs of the people you work with, doesn't suck.

I've noticed they've stopped teaching assembly language. Perhaps measuring clock-cycles might do some of these guys some good. Of course, there is always the counter-argument, "Oh, you're not writing object-oriented code then." Bullsh*t, OO is about encapsulation, inheritance, and polymorphism. A well written OO program is less code that is easier to follow than a well written procedural program. But, it seems a lot of people have to go to extremes instead of looking for that perfect balance, thinking somehow you have a baby, bathwater, but never the two may mix!

You know (I'm in a crazy mood today, it seems), what is up with people's sense of logic today? It's like society has them so screwed-up they can't see any simple correlations any more. I'm getting tired of suffering fools who think that writing these big programs to automatically populate object information that include 20 or so extra libraries, each in their own containing a plethera of bad, crap code that depends on other bad, crap code is a good idea. And what is with jury-rigging everything into XML these days. Configuration files shouldn't be XML, damnit, it's too much overhead. What happened to the KISS principle? Were the configuration files of the past where you had lines of something equal to something else in sections that a dog could read, understand, and provide meaningful error messages instead of lazy messages that says, "Go look at the DTD," bad?

Sorry, the frustration is showing. Go ahead and mod me rant.