Mappings defined in abstract class not reflected in child table

[SpaceCowboy]

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.


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

[pledbrook]

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.

[SpaceCowboy]

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.

[SpaceCowboy]

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.