Any interest in a Torque DAO implementation?

[Migrated From Jforum.net]

In looking at integrating JForum with our software, I've developed a DAO implimentation based on the Apache Torque OM layer ( http://db.apache.org/torque ). Would the jForum team be interested in having this contributed to the project?

I've tested all the basic functions against MySQL and it seems to be working find. I'm getting ready to try it against MS SQL. FWIW, I need MS SQL support, so I started to debug the existing MS SQL DAO. But since I'm a long time user, supporter, contributer to the Torque project, I decided to go this route.

Here's some info on Torque:

Torque is an object-relational mapper for java. In other words, Torque lets you access and manipulate data in a relational database using java objects. Unlike most other object-relational mappers, Torque does not use reflection to access user-provided classes, but it generates the necessary classes (including the Data Objects) from an XML schema describing the database layout. The XML schema can also be used to generate and execute a SQL script which creates all the tables in the database.

What this means is that:

I've modeled the jForum DB schema into Torque's XML format. This was used to generate a set of OM objects that were used with Torque's generic
Criteria functions to create the DAO. In theory, this should allow jForum to run with on any of the 18 relational databases that Torque supports.

In addition, Torque can use the Schema XML to generate SQL scripts to create the schema for any of it's supported DBs via an Ant (or Maven) target. Just set the build properties to the DB you want, call the Torque sql target, and you get a DB specific script for table generation.

Modifying the schema become a simple matter of changing the XML, regenerating the OM objects, changing a single DAO to use the new table/columns, and then regenerating the database build scripts.

(Ok, I admit, I'm a Torque-a-holic...)

There are some warts here and there, but this seems like a good enhancement for jForum... and I like contributing to open source projects.

Greg




[originally posted on jforum.net by monroe]

[Migrated From Jforum.net]

I'm not really anyone to listen to, but I'd love it. My webhost doesn't allow Hibernate, so I'm SOL on upgrades if an alternative isn't provided in 3.0.
[originally posted on jforum.net by jbanes]

[Migrated From Jforum.net]

JForum 3 is being built on the top of Hibernate 3 and Java 5.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Not a bad choice.. ( IMHO, just a lot more code writing and XML bookwork bugs that can compilers can't catch.. , but I've already said I'm biased )

Is the DAO layer still going to exist in 3.0? It really makes my life easier to have a Torque DAO implimentation that works well with the application I'm integrating with.

If there's enough interest, I'll package my Torque DAO as an add-on available elsewhere.
[originally posted on jforum.net by monroe]

[Migrated From Jforum.net]

No, the DAO layer is over - there was a discussion behind the scenes about that, and the conclusion was that having interfaces for the DAOs doesn't make much sense when you're using hibernate.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

If anyone is interested, I've finished my Torque DAO implimentation for jForum 2.1.6 (working on a 2.1.7 version). It's been tested against new installs with MS SQL Server and MySQL 5.0 but should work for most of the other DB types that Torque supports. It "should" work against existing jForum tables but I haven't tested it and there may be some XML schema tweaks needed to match existing column types to Torque types.

I've licensed it with the JForum license (in case you change your minds..) But reserve the right to change it to the Apache 2 License.

You can get the binary and source distros from:

http://people.apache.org/~gmonroe/jforum

Attached are the Install.txt and build.txt docs included in the distro.

Jforum developers might want to take a look at the "Creating a new DB type" section in Build.txt to get an idea of some of the benefits that Torque supplies.




[originally posted on jforum.net by monroe]

[Migrated From Jforum.net]

hi-

Torque noobie question: Except for abstraction, what does torque offer over the current DAO for MySQL (only)?


[originally posted on jforum.net by MyJForum]

[Migrated From Jforum.net]

Not a bad question.

If jForum has a "native" DAO that's well tested, then go for that. I referenced MySQL because because I wanted to test that I didn't have problems with cross DB support, sometimes constraints and field definitions need to be tweaked in Torque's XML schema to get them to work for multiple DBs. MySQL was handy to use as a second test DB server.

The key to choosing a DAO is "well tested", in doing this I have noticed updates to the MySQL scripts that were not carried over to other DB types.
So, less used DAO's may have unfixed issues. With the Torque abstraction, fixing a problem once fixes it for all DB servers.

FWIW, I actually did this because I needed MS SQL support and all the solutions I found here had issues with invalid queries in various places. Rather than work all the bugs out of them and since that app I'm integrating jForum with uses Torque, I decided to create a stable MS SQL implimentation in Torque. Which also creates a quick way to create stable implimentations for DB2, Derby, Firebase, and a bunch of other Torque support DBs that jForum doesn't support.

All of this is do-able with Hybernate that jForum 3.0 is moving towards, but I couldn't wait. And just thought I'd give back to the community if folks wanted it.


[originally posted on jforum.net by monroe]

[Migrated From Jforum.net]

monroe wrote:Not a bad question.

If jForum has a "native" DAO that's well tested, then go for that. I referenced MySQL because because I wanted to test that I didn't have problems with cross DB support, sometimes constraints and field definitions need to be tweaked in Torque's XML schema to get them to work for multiple DBs. MySQL was handy to use as a second test DB server.

I believe DAOs are a bad idea in these days of transparent persistence - they're old fashioned, time consuming and unnecessary.

However - persistence engine independence is GOOD!!! and if you use the "exposed domain model" pattern with the open source exPOJO framework http://expojo.com then your application code can remain completely persistence engine agnostic - which is great: users can run your application using any object relational mapper - Hibernate and JDO supported right out of the box, JPA coming soon if enough demand and any other ORM (Torque?) can be supported if you have a spare 20 minutes to create the appropriate wrapper!

The exposed model pattern's concept of repositories and services is also a great way to assemble reusable model access and lookup functionality that your application code uses.

[originally posted on jforum.net by golfman]