Discussions

Industry news: FireStorm/DAO 3.0 RC1 Java Persistence Code Generator

  1. FireStorm/DAO 3.0 is feature complete and the release candidate is now available for download. The important new features are Hibernate support and enhanced support for Oracle Stored Procedures. The list of new technical features includes dynamic SQL with custom SQL DAOs, setMaxRows support, and setting default Values for DTO fields.

    FireStorm/DAO now also supports both DAO and ORM code generation.


    Detailed feature descriptions are available on the CodeFutures Support Blog.

    CodeFutures believes that there is no one perfect Java persistence technology. Every major release of FireStorm/DAO has added a new Java persistence option starting with JDBC, then adding JDO and EJB CMP, and now Hibernate.
  2. 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.

    I might be wrong in my analysis. Please let me know if you feel that some of these shortcomings cam be overcome somehow.
  3. Hi Nikhil,
    From my first analysis Firestorm 3.0 looks like a great tools but also seems to have certain shortcomings

    Thanks! Let me try and address some of the perceived 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.

    FireStorm/DAO offers two flavours of code generation - DAO and ORM. The DAO pattern uses simple DTO classes to represent rows in each table and does not maintain object graphs than get passed around. The ORM code generation option will give you this behaviour (this is available for JDO and Hibernate). The ORM code generation feature is new as of version 3.0 and does not directly support many-to-many relationships but we are working on this.
    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.

    FireStorm/DAO does generate isModified() methods that should handle this need. It also provides the option of generating dynamic insert and update statements that only insert/update modified fields rather than updating every field on a row when only one field is modified.
    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.

    It is very easy to modify the code generation templates to support this. This is probably the first customization that our customers make. This does require the Architect Edition of the product rather than the Enterprise Edition. In fact, with the Architect Edition you get the complete source code for the code generators so pretty much any customization is possible.
    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.

    We usually recommend manually writing a facade to provide the abstraction you need.
    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.

    FireStorm/DAO supports two modes of transaction management. You can supply your own Connection object to the DAO if you want to manually control transactions or you can use the default behaviour which is for the DAO to make a call to a customizable ResourceManager class to get a connection when it needs one. The default implementation of this class under J2EE is to perform a JNDI lookup to obtain a connection. This enables you to use the J2EE servers transaction management capabilities.
    6. A separate Manager class (static or singleton) would have helped to provide transparent transactions as well as unit of work.I might be wrong in my analysis. Please let me know if you feel that some of these shortcomings cam be overcome somehow.

    Hopefully the above answers have been useful. We are in the process of writing more detailed technical documentation for the GA launch of FireStorm/DAO 3.0 which will help address these sort of concerns for our customers and evaluators.

    Thanks,

    Andy Grove
    CTO
    CodeFutures Software
  4. only insert/update modified fields[ Go to top ]

    Hi Andy, Currently we are working for a new project in which we are in the process of studying tool for the code generation including presentation layer. We come across your product and we started evaluating the tool. We like your tool. While evaluating this tool,The insert/update modified fields not working properly.Even i am selecting these option the entire code will be re-generated, my modified code will be lost. please let me know what is the issue. Regards Suresh Natarajan