Announcement Announcement Module
No announcement yet.
Using Roo with an existing database Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Version and Id modifications

    Existing table with no version field:
    I tried setting --versionField "" in the script that created my entity but that didn't add the versionField = "" to the @RooEntity() annotation in my model class.
    In order to get it to work:
    • I manually added versionField = "" to the @RooEntity() annotation in my Pim model
    • I also had to add the @Transient annotation to the version field in the generated Pim_Roo_Entity.

    Existing table with id other than "id" using a SEQUENCE
    By creating the entity using --identifierField id --identifierColumn id_pk in the script as previously described, I was able to generate a working app that used my id_pk field. It was a bit trickier to get the app to use my SEQUENCE to generate the id value, but I finally did:
    • I removed the identifierField="id", identifierColumn="id_pk" from the Pim model
    • I manually edited my Pim class with the following:
      Just above the @RooEntity line, I added:
      @SequenceGenerator(name="IdSeq", sequenceName="person_id_mapper_pk_seq")

      Then, I added the GenerateValue line after the @Id line:
      @GeneratedValue(strategy = GenerationType.SEQUENCE, generator="idSeq")
      @Column(name = "id_pk")
      private Long id
    • I then generated setters/getters for id in the Pim model
    • I also had to comment out the @Id section from Pim_Roo_Entity, including the field and the getters/setters, since it did not update this for me.

    When I originally executed the "controller scaffold" command, my table did not have the "DELETE" privilege, so the generated application did not include Delete capabilities. Is there a way to re-generate the controller and all of the scaffold views?
    Last edited by qualcommLisa; Nov 9th, 2009, 07:35 PM.


    • #17
      Ben, I ran into the issue where roo will always generate the id field as being a Long datatype? I know that you can manually move the id field into the entity class to override the datatype with the Column annotation but it seems like the "entity" addon could give a additional argument of the id datatype so that the id field could stay in the aspect source.

      What do you think?


      • #18
        The "entity" command already accepts a relatively large number of arguments (10 at present) so my normal reaction would be to say we should try to keep the command focused on the mainstream use cases. However, we already support specification of identifierField (field name) and identifierColumn (column name) via the command so in the interests of consistency and convenience it is probably worth doing. Please feel free to log a Jira issue at and we'll be pleased to take a look at it.


        • #19
          Jira Created


          Here is the enhancement request.


          • #20
            For those following along, ROO-413 was completed within 30 minutes of being logged yesterday. So it'll be in Roo 1.0.0.RC4.


            • #21
              Roo + JAG / GRAG

              Me too I'm interested.

              It'd be handy for all of us who have an existing demo app in Mysql to see what Roo would create when feeding it with the data source url.

              A bit like GRAG is doing for Grails or JAG for Java applications.

              Or, doing like GRAG did, piggybacking on JAG..

              Too bad my time is so scarce for a plugin dev..
              Last edited by stephaneeybert; Nov 27th, 2009, 08:34 AM.


              • #22
                I've created a new Jira issue - - for database reverse engineering. Votes and comments are welcome in Jira for this.


                • #23
                  Hi Ben, the issue is one of the most popular issues, in which release will you include it?



                  • #24
                    It's very high up my priority list. Even Rod Johnson has asked me to do it, so it'll get done. :-)

                    Realistically we'll be focusing on 1.0.1 in January and some scoping work to do with the GWT feature. I'll likely get to it in February. Contributions, as always, are very welcome. A valuable first pass would be to introspect a DB and create some value objects that represent the desired entities, fields and the correct JPA annotations that should go on them. If we had such value objects it would be trivial for me to finish the job by causing Roo to amend the project files properly. It would also allow database-specific adapters to be written where required.


                    • #25
                      Hi Ben,

                      We (DiSiD team) are working on this issue. Our approach would be to develop an addon that uses Hibernate Tools and custom Hb Tools Templates to generate Entities with both Roo and JPA annotations.

                      We have splitted the work in 2 phases:

                      1. Develop custom hbt templates and use Hibernate Tools manually to generate Roo Entities
                      2. Develop the addon that manages the reverse eng. process. Basically the addon should give us options to customize the rev. eng. process (i.e. by managing hibernate.reveng.xml) and it should run the rev. eng. process.

                      We would like your thoughts about this approach.



                      • #26
                        I also saw someone using the Eclipse 3.5 "create entities from database" feature yesterday, and that works with Roo apps. So you need not use Hibernate Tools unless you particularly wish to...

                        Native database introspection will be part of Roo 1.1.0.


                        • #27
                          Ben, is the "create entities from database" a standard feature of Eclipse 3.5?


                          • #28
                            Hi Ben,

                            We don't have special interest in using Hibernate Tools Some time ago we searched for one tool/lib for reverse engineering that was independent of any IDE and integrated into our build cycle (Maven2 or Ant). This is the reason because we chose HBT.

                            Native database introspection will be a great feature but I don't know when it is planned to release this feature. In the meantime, it is a good option to use HBT manually (see phase 1 posted above).

                            Ben, reverse engineering is one of the most powerful features of HBT, it gives us a fine control over rev. eng. process: schema selection, type mappings, table filters, table configuration, etc. Please, take a look at it, it could come in useful to elaborate Roo native support requirements.

                            Just to know, which is the problem you see in an HBT addon?


                            • #29
                              I don't see any problem specifically with the Hibernate Tools approach, I was just letting you know there is an alternative. I must confess, though, that I haven't used HBT for quite some time and last time I did it was adding Hibernate proprietary annotations to the created types. The Eclipse approach only used standard JPA annotations, which is obviously preferred (and HBT may indeed do that these days as well).

                              Roo will use its own from-scratch reverse engineering approach as opposed to building on these existing approaches. I want to leverage the ITDs as part of the reverse engineering, so people can re-introspect a DB at any time and update the ITDs accordingly.


                              • #30
                                Re-instrospection sounds really good Thanks for sharing!