Mailing-List: contact torque-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Users List" <torque-user@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
In-Reply-To: <DC6FE147362C62489838F079C478E0C372E0BD@blr02.bynum.com>
Subject: RE: torque vs hibernate
To: "Apache Torque Users List" <torque-user@db.apache.org>
Message-ID: 
 <OF78AE37E7.C9F87A0D-ONC12572B2.0028E892-C12572B2.002CDBE5@seitenbau.net>
From: Thomas Fischer <fischer@seitenbau.net>
Date: Tue, 3 Apr 2007 10:09:58 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII

This seems to come up every year or so :-) . Comments below.

"jill han" <jhan@bynum.com> schrieb am 02.04.2007 21:42:52:
> Recently, a consulting firm evaluated our current
> turbine/torque/velocity application.
> Here are what they say about Torque,
> 1)Torque forces the definition of one-to-one mapping from relational
> model to business model. One-to-one mapping limits the design of
> business domain objects to the design of the database relational model.

I do not understand what they say by that. Do they imply that Torque
objects cannot have attributes which are non-persistent (which si untrue,
you can define them in the non-Base objects) ? Or do they mean that Torque
does not provide an out-of-the-box mapping between database objects to
business object ? I doubt that other O-R-Mappers can provide that.

> 2)The Torque O/R mapping framework prepares dynamic SQL statements for
> data access. This form of data access is slower than directly calling
> stored
> procedures in a relationship database like Oracle.

This is only important if you have many "cheap" queries (cheap means that
the database does not have much trouble in executing), where the overhead
of parsing the queries by the database is significant. If you have
expensive queries, the overhead of parsing the queries is totally
irrelevant. Besides, you need people which have experience in writing
stored procedures. Do you have access to such people ? Also using stored
procedures leads to throwing away the database independence of your
application.

> 3)Torque does not contain built-in help for version checking. As a
> result, this feature will require a custom implementation for future
> enhancements.

I do not understand what that means. Could you explain what they mean by
"version checkin"? An example would be great.

> 4)Hibernate gives more flexibility in mapping relations, especially in
> mapping many-to-many relations. The ability to map many-to-many
> relationships helps the design of the business entities better
> represent the business domain. We recommend the implementation of
> Hibernate.

Torque would certainly benefit from being able to map
many-by-many-relations out of the box. However, it is not very difficult to
create the many-by-many-relations via a mapping table. The code overhead to
do that is small, so unless you have many many-by-many-relations, I do not
see this as a major problem.

> I really don't know how to defend torque in the perspectives of
> architecture, design, and etc.
> Please help.
> Thanks a lot.

To understand why the consultants raised these points, it would be helpful
to know why the consultants evaluated your application. Were there
performance problems, does anybody expects to develop applications faster,
does the application often fail in not-thought-about special cases ?
I do not think that they found very strong points against Torque. And
usually I do not tend to believe anybody who finds just bad things in one
way of doing something (using Torque) and does not also points out risks in
doing it otherwise (using hibernate). For example, you could point out the
following:
- The licence. It is problematic to tune hibernate if you need to do so.
- The developers are used to Torque. It will take time for them to get used
to hibernate.
- (I do knot know if this applies) Some years ago, when you have chosen to
use Torque, it was not so clear that hibernate would become as big and
well-documented as it is now.
- Torque is simple. This divides into several sub-points:
  - If you have a problem, you can debug into the source code and see what
happens. And no, the point is not about not having the source code of
hibernate, the point it it is very difficult to understand with all the
reflection stuff going on, and hibernate being huge. Try debugging Torque,
and try debugging hibernate, and you understand what I mean.
  - Torque has an 1:1 mapping of commands to db operations. Meaning, if you
want to execute a select you call the doSelect statement, and you have very
good control about how the sql of the statement looks. In hibernate, you do
not have the control over the sql. This means that you loose opportunities
to performance-tune your application, or do stuff like "if I save this
object, I also want its changeDate to be updated to the current time" etc.
- Hibernate is very sluggish on start-up (this is not important for
long-running applications, but it is important for command-line tools)

To put it into a nutshell, I do not think that Torque is better than
hibernate, or the other way round. There are situations where Torque is
suited better and other situations where hibernate is better. In my
personal opinion, if you want to have control about what is happening in
the database, use Torque. If you want an  O-R mapper which tries to
implement the "do what I think"-Button, use hibernate.

    Thomas


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org