Announcement Announcement Module
Collapse
No announcement yet.
Mappings defined in abstract class not reflected in child table Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mappings defined in abstract class not reflected in child table

    Hello,
    I have an issue and wondered whether this was a grails 1.3.3. bug or me not understanding grails ?

    To summarize: Mappings defined in abstract class do not get reflected in child domain class table

    The test case:

    I have a basic domain class that extends an abstract class and some mappings in both.

    Code:
    public abstract class AbstractAirline {
    	static mapping = {
    		id column: 'airline_id'
    		name column:'airline_name'
    		description column: 'airline_details'
    	}
    	
    	String name
    	String description
    }
    
    class Airline extends AbstractAirline{
    	
    	static mapping = {
    		table 'airline'
    		frequentFlyer column: 'frequent_flyer'
    		iata column: 'iata_number'
    	}
       
    	String frequentFlyer
    	String iata
    }
    The result:
    However when GORM generates the tables it does not honour the mappings from the abstract class, so you end up with the default names and id:

    PUBLIC.AIRLINE
    ID
    VERSION
    DESCRIPTION
    FREQUENT_FLYTER
    IATA_NUMBER
    NAME

    The expected result:

    PUBLIC.AIRLINE
    AIRLINE_ID
    VERSION
    AIRLINE_DETAILS
    FREQUENT_FLYTER
    IATA_NUMBER
    AIRLINE_NAME

    Any help would be appreciated,
    Thanks

  • #2
    As I understand it, abstract domain classes don't get a table definition, which is possibly why mappings aren't included. If you make it a concrete domain class, the mappings block will work.

    Is there a particular reason the class is abstract, or that you want to put the mappings in there? Perhaps there's a better approach.

    Comment


    • #3
      Thanks for the quick response, the reason is that im taking a legacy app and moving it bit by bit to grails, that was just an example i put up but in the real app these abstract base classes are used to form many other more specific classes. The hierarchy all make sense and abstracts and interfaces are used in places that make sense. I dont want to lose that power, or sensibility by laxing on protection by removing abstracts and interfaces and private fields etc.

      But your right, if that is a dead cert limitation with grails then fair enough, concretes it is.

      Comment


      • #4
        i guess the other point is that it maps the abstract properties fine, so the table DOES contain those properties in the final child table but what does not work is the mappings block where i rename the columns.

        Comment

        Working...
        X