10 Replies Latest reply on Nov 18, 2005 8:34 PM by Mark Sobkow

    Is there any way to collapse atrophied tables?

    Mark Sobkow Newbie


      Let's say you have an object hierarchy A-B-C-D. The base class A specifies a discriminator and JOINED inheritance strategy.

      Classes A, B, and D have persistent detail attributes, but C only defines transients and methods without persistent details.

      Is there any way to tell EJB3 that there is no actual table for C? It's easy enough to do the RDBMS scripts so that D.PKey references B.Pk, but I can't think of a way to have the EJB entities match that mapping.

      If it's a "future" feature, I can work live without it for now. But it would be a lot easier to define and implement object hierarchies that are rich in business functionality difference but lean on persistent details. (e.g. Person might be the base for Employee, Manager, Customer, etc. with very different business roles and methods even though they don't collect any new information about a Person.)

        • 1. Re: Is there any way to collapse atrophied tables?
          Emmanuel Bernard Master

          How do you know if C is actually of type C

          • 2. Re: Is there any way to collapse atrophied tables?
            Mark Sobkow Newbie

             

            "epbernard" wrote:
            How do you know if C is actually of type C


            Each class in the hierarchy specifies @Inheritance( discriminatorValue=blah).

            In the example below, EmployeeRec is atrophied.

            The problem is that if you don't specify @Table, the spec assumes there is a table with the same name as the class. If there were an @NoTable tag the provider could still determine the class from the discriminatorValue stored in the base table.

            @Entity( access=AccessType.FIELD )
            @Table( schema="people", name="person" )
            @Inheritance( strategy=InheritanceType.JOINED,
             discriminatorType=DiscriminatorType.STRING,
             discriminatorValue="PERS" )
            @DiscriminatorColumn( name="classcode" )
            public class PersonRec
             implements Serializable
            {
             @EmbeddedId
             PersonRecPKey pKey;
            
             @Column( name="fname", nullable=true,
             insertable=true, updatable=true )
             String firstName;
            
             @Column( name="lname", nullable=true,
             insertable=true, updatable=true )
             String lastName;
            
             ...
            }
            
            
            @Entity( access=AccessType.FIELD )
            @Table( schema="people", name="assoc" )
            @Inheritance( discriminatorValue="ASOC" )
            @PrimaryKeyJoinColumns( {
             @PrimaryKeyJoinColumn( name="Id",
             referencedColumnName="Id" ) } )
            public class AssociateRec
             extends PersonRec
             implements Serializable
            {
             @Column( name="corpid", nullable=false,
             insertable=true, updatable=true )
             String corporateId;
            
             ...
            }
            
            
            @Entity( access=AccessType.FIELD )
            @Table( schema="people", name="emp" )
            @Inheritance( discriminatorValue="EMPL" )
            @PrimaryKeyJoinColumns( {
             @PrimaryKeyJoinColumn( name="Id",
             referencedColumnName="Id" ) } )
            public class EmployeeRec
             extends AssociateRec
             implements Serializable
            {
             // No new attributes, but class implies
             // access to corp HR systems, etc.
             // Methods provided for linking to payroll
             // deposit info, etc.
            }
            
            
            @Entity( access=AccessType.FIELD )
            @Table( schema="people", name="ftemp" )
            @Inheritance( discriminatorValue="FEMP" )
            @PrimaryKeyJoinColumns( {
             @PrimaryKeyJoinColumn( name="Id",
             referencedColumnName="Id" ) } )
            public class FullTimeEmployeeRec
             extends EmployeeRec
             implements Serializable
            {
             // Maybe new attributes, but more importantly
             // class implies access to HR benefits systems
            }
            
            
            @Entity( access=AccessType.FIELD )
            @Table( schema="people", name="ptemp" )
            @Inheritance( discriminatorValue="PEMP" )
            @PrimaryKeyJoinColumns( {
             @PrimaryKeyJoinColumn( name="Id",
             referencedColumnName="Id" ) } )
            public class PartTimeEmployeeRec
             extends EmployeeRec
             implements Serializable
            {
             // Maybe new attributes, but more importantly
             // class does not have access to benefits systems
            }
            


            The class of the entity also comes into play for the UI, which adds or removes frame tabs for the remote systems based on the class of person being displayed.

            • 3. Re: Is there any way to collapse atrophied tables?
              Emmanuel Bernard Master

              The spec state, that only implementations that needs the discr column in JOINED should use it. Hibernate don't :-)

              • 4. Re: Is there any way to collapse atrophied tables?
                Mark Sobkow Newbie

                Ok, I can see how Hibernate could avoid the discriminator attribute by relying on inner joins to tell it what class an object is when queried, but that also prevents it from being able to collapse atrophied tables, doesn't it?

                I'll have to think on this a while, as the discriminator column was making it easier to do the SQL for reporting/extraction. In some cases I'd end up having to do a 20-30 table join/union to infer the class without a discriminator, and there are no RDBMS products on the market that can handle such queries efficiently. (IIRC anything more than about 11 tables goes beyond the optimization algorithms most databases have.)

                • 5. Re: Is there any way to collapse atrophied tables?
                  Emmanuel Bernard Master

                  I'm going to implement @EmbeddedSuperclass in the middle of the hierarchy for this kind of issue.

                  • 6. Re: Is there any way to collapse atrophied tables?
                    Mark Sobkow Newbie


                    In the meantime I was able to restructure my class hierarchy to eliminate the atrophied tables. It's a bit more verbose (more tables/classes), but it will work. Instead of making the functionality part of the hierarchy, I used 1:0,1 relations to an optional component table and use a full/part time flag to indicate whether the relation should be established.

                    As a side benefit, an employee who leaves and returns under a different job class will have the details of their previous employment status retained. (e.g. Full timer leaves, comes back as part time/contract, benefits details still exist but are not active. If later reinstated to full time, a simple flag change re-enables the benefits details instead of having to mutate the instance.)

                    The spec has an @EmbeddableSuperclass -- are you talking about extending it's functionality or a new annotation? I hadn't gotten the impression that an @EmbeddableSuperclass could inherit from a real table class, but was more of a virtual base class notation.

                    • 7. Re: Is there any way to collapse atrophied tables?
                      Emmanuel Bernard Master

                      reuse embeddablesuperclass as a mark to embed the class property in the subclasses avoiding atrophied tables.

                      • 8. Re: Is there any way to collapse atrophied tables?
                        Mark Sobkow Newbie

                        Just to clarify, are you talking about making the atrophied table classes an @EmbeddableSuperclass? That would imply that an @EmbeddableSuperclass can inherit -- a powerful syntax indeed! :)

                        • 9. Re: Is there any way to collapse atrophied tables?
                          Emmanuel Bernard Master

                          I guess we are saying the same thing, but to be honest, I'm not really sure ;-)

                          • 10. Re: Is there any way to collapse atrophied tables?
                            Mark Sobkow Newbie

                            I'll give it a try when I have some time and let you know if it worked.

                            I'm going to be a bit busy with a work-related move for the next week or two, but I'll try out my thoughts as soon as can and post the samples (either to explain what I mean or to show what I found to work, depending on how things go.)