Announcement Announcement Module
Collapse
No announcement yet.
Issues with abstract classes and spurious JPA identity fields Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Issues with abstract classes and spurious JPA identity fields

    I'm running Roo 1.0.2 via STS 2.3.1 and think ROO is really cool and helpful. But why does ROO seem to ignore the identity field I specify in my ROO entity script:

    entity --class com.a2innovate.domain.A2IUser --abstract --inheritanceType SINGLE_TABLE --identifierField id

    field number --class com.a2innovate.domain.A2IUser --fieldName id --type java.lang.Long --notNull

    An excerpt from the generated class is:

    @Entity
    @RooJavaBean
    @RooToString
    @RooEntity(identifierField = "id")
    public class A2IUser {

    @NotNull
    private Long id;

    An excerpt from the corresponding Entity.aj is:
    privileged aspect A2IUser_Roo_Entity {

    @PersistenceContext
    transient EntityManager A2IUser.entityManager;

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "_id")
    private Long A2IUser._id;

    So I have several questions:
    1. Note that the generated java class is not abstract. Why was the --abstract specification on the Roo entity definition ignored. (Note that I have tried that clinic.roo script and that seems to generate the class as "public abstract", which is what I would expect. That would seem to point to a problem with my roo entity specification, but I'm not seeing the problem.)

    2. Why does roo generate a second identity field (_id), when I clearly designated the field "id" to be the entity identity field ( "--identifierField id").
    And how should I remove the spurious field from the ...Roo_Entity.aj file? (My understanding is that we are not supposed to edit those files.) Both "id" and "-id" show as columns in the database table.

    As a follow on, I have tried editing the java file to explicitly designate the "id" field as the identity field:
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "id")
    @NotNull
    private Long id;
    but after roo regenerates the corresponding Roo_Entity.aj file it still contains "_id" annotated with @Id.

  • #2
    Follow on observations

    I did some experimentation and found there is also a "version" field that is automatically generated (in addition to the "_id" field).

    Now, there appears to be no way to specify a "version" field via the roo command line. But even after defining a @Version field of the allowable types and with a different name, your XXX_ROO_Entity.aj file still seems to generate its own version field (and it refers to that field, not the one the user designated in the persistence methods.

    Comment


    • #3
      The roo cnd line arguments are order-dependent

      I was browsing this form for answers when I noticed a small roo script that Ben Alex provided. It had the command line arguments as I used - just reversed! I tried that and it works.

      So the following works (labelling the class as abstract):
      entity --class com.xxx.domain.A2IUser --inheritanceType SINGLE_TABLE --abstract

      But the following does not:

      entity --class com.xxx.domain.A2IUser --abstract --inheritanceType SINGLE_TABLE

      As far as I could tell from the the argument hints provided by roo command line processor, both "--asbstract" and "--inheritanceType" are optional. My understanding is that all the optional arguments are not dependent on order, so this seems like a bug.
      If someone who knows ROO better than I could confirm this, I'll submit a bug.

      Comment


      • #4
        More on the @Id and @Version issues

        After much experimentation, I've come to the conclusion that the ROO processor ignores any @Id and @Version annotations that you place in your domain object classes. So I've learned to not attempt to specify any identity fields in roo scripts, and not to add any @Id and @Version annotations to the java classes. That approach works, but it seems to contradict the philosophy that "Roo inspects your class and does not handle anything that you have explicitly coded.

        I'd appreciate any insights from folks who understand roo better than I.
        Thanks.

        Comment


        • #5
          Can you please summarize your findings and suggestions and open an improvement ticket in the Roo Jira? This would allow us to follow this up.

          Thanks,
          Stefan

          Comment


          • #6
            I have similar problems but not regarding abstract classes.

            I open a new thread:

            http://forum.springsource.org/showth...081#post297081

            Comment

            Working...
            X