Summary
CodeFutures, the Java persistence software tool vendor, today announced the availability of a FireStorm/DAO 3.0 Release Candidate 1.
Advertisement
CodeFutures, the Java persistence software tool vendor, today announced the availability of a FireStorm/DAO 3.0 Release Candidate 1. FireStorm/DAO makes Java software developers more productive by automatically generating Java source code for accessing relational databases. CodeFutures' Java code generation approach cuts costs through higher developer productivity, better software quality, and lower maintenance costs.
"We have added Hibernate support as another Java persistence option in FireStorm/DAO, which also supports JDBC, JDO, and EJB CMP. We have also continued to focus on product usability features and the rest of the new features in this release are customer-requested technical improvements that make FireStorm/DAO easier to use." says Andy Grove, CTO, CodeFutures Software.
"By adding Hibernate support, CodeFutures tapped into a new target market and also expanded on FireStorm/DAO's unique support for multiple Java persistence technologies" says PJ Murray, CEO, CodeFutures Software.
The technical enhancements to FireStorm/DAO in Release 3.0 are:
Hibernate code generation
FireStorm/DAO makes Hibenrate Java developers more productive by generating Java code and configuration files that would otherwise have to be manually produced. FireStorm/DAO produces Hibernate persistent classes and a Hibernate mapping file (*.hbm.xml) for each database table.
REF CURSOR support for Oracle Stored Procedures
FireStorm/DAO reverse-engineers stored procedures for Oracle, SQL Server, and Sybase. Oracle support has been enhanced and FireStorm/DAO now reverse-engineers REF CURSOR parameter information, including REF CURSOR columns, when importing Oracle Stored Procedures.
Using Dynamic SQL with Custom SQL DAOs
It is now possible to execute Custom Data Access Objects with dynamic SQL. Effectively this means that the same DTO and DAO mapping can now be used with multiple SQL statements. A typical use-case for using Dynamic SQL statements with a Custom DAO is where a multi-table SELECT is implemented as a Custom DAO but there is a need for multiple "finder" methods.
setMaxRows Support
JDBC DAOs for Tables and Views now have a setMaxRows() method. This method should be called prior to calling any finder methods to limit the number of rows returned (the DAO finder implementations simply makes a call to JDBC setMaxRows method before executing their SQL query).
Setting Default Values for DTO Fields
Users can set default values for DTO fields when defining Table and View DAOs through the FireStorm/DAO user interface. Typical uses of this feature would include allocating UUID values to primary key fields and defaulting date fields to today's date.
User Interface and Usability Improvements
There are many usability improvements, for example, when re-installing or upgrading FireStorm/DAO, existing firestorm- conf.xml files are no longer overwritten.
I am in the process of evaluating different data access technologies and tools available. Based on that I would be able to give suggestions to the project teams across the company.
Our interest in Firestorm is more because of its ability to generate dataaccess tier using pure JDBC. Support for Hibername and JDO is always welcome, but there are plenty of tools in that sphere anyway.
From my first analysis Firestorm 3.0 looks like a great tools but also seems to have certain shortcomings:
1. FireStorm does not directly supports many-to-many relationships. SQL2JAVA with is a much simpler code generatio tool supports that. For instance suppose users table has many to many relationship with projects table and UserProject is the join table. I expect to see a method (getProjects()) in the user class (generated by reverse mapping) which should return a collection of projects objects for that user. From the classes that are getting generated right now, the only option I have got is to get the collection of UserProject objects and then extract each Project object individually. That would make me fire n+1 queries instead of just one query apart from making it more complicated to use.
2. FireStorm does not have the unit of work support. Since firestorm is generating the classes it should be possible for it to have a mechanism for dirty flagging the changed objects. That would enable a manager to intelligently find out the changed objects and persist just those objects when the user sends the signal to end the unit of work
3. There is no way to configure FireStorm so that the generated DTO classes extend a custom class. That might help us inject our own unit of work mechanism.
4. Each stored procedure gets represented by a separate DAO and a custom DTO object. There is no way to move that method in an existing DAO in order to group data access methods logically.
5. Transaction management is not transparent. User would have to get a connection object and create the DAO object from that connection in order for the DAO objects to participate in the same connection.
6. A separate Manager class (static or singleton) would have helped to provide transparent transactions as well as unit of work.
7. The DAO layer for hibernate exposes copies of the persistent objects instead of the persistent objects themselves. Thus for each call the DTO objects have to be translated back ond forth to the persistent objects that hibernate works on..
Previous Topic
