Andreas,
No you don't have to map the discriminator column
explicitly. The model looks to be defined correctly, so its very odd that it would be null.
What does your
execution code
look like? I'm
not well
versed in Scala but perhaps
the discriminator value is being 'lost'
somewhere along the way?
Hm, strange, persisting the same type other places works.
Do you have any pointers to where the value is retreived
from when generating the INSERT-query so I can debug and
step thru it to se what's going on?
Thanks.
[snip]
I've tracked down som info:
ObjectBuilder:1560
public AbstractRecord buildRow(AbstractRecord databaseRow, Object object, AbstractSession session, WriteType writeType) {
// PERF: Avoid synchronized enumerator as is concurrency bottleneck.
List mappings = this.descriptor.getMappings();
int mappingsSize = mappings.size();
for (int index = 0; index < mappingsSize; index++) {
DatabaseMapping mapping = (DatabaseMapping)mappings.get(index);
mapping.writeFromObjectIntoRow(object, databaseRow, session, writeType);
}
// If this descriptor is involved in inheritance add the class type.
if (this.descriptor.hasInheritance()) {
this.descriptor.getInheritancePolicy().addClassIndicatorFieldToRow(databaseRow);
}
My class-hierarchy is:
EmailPart (abstract)
|--> EmailSinglePart - @DiscriminatorValue("singlepart")
The strange thing here is that the value of
this.descriptor.javaClass is the abstract EmailPart.class and
not EmailSinglePart.class in this special case where it's not
working. Other places in the application the value is
EmainSinglePart and then it works correctly.
This results in a null-value being set for the
discriminator-column, by the marked
addClassIndicatorFieldToRow() method, because it uses the
class-object returned from descriptor.javaClass to lookup in the
Map descriptor.inheritancePolicy.classIndicatorMapping, which
does not hold an entry for the abstract parent-class.
Digging for more info on how this is possible.
Comments are welcome:-)
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
--
Guy Pelletier
ORACLE Canada,
45 O'Connor Street
Suite 400
Ottawa, Ontario
Canada K1P 1A4
Oracle is committed to developing practices
and products that help protect the environment
