Andreas,
Did you try removing the abstract
declaration on EmailPart?
No, I will try it.
But this works when persisting objects of type
EmailSinglePart in other places of the application so it would
be nice to understand what's going on. I really don't want
programmers to be able to instantiate EmailPart directly so
I'd prefer if it could remain abstract but will test to see if
it helps.
Do you have any pointers to where ObjectBuilder.descriptor
is created so I can see why EmailPart.class is used and not
EmailSinglePart.class?
Removing "abstract" results in EL inserting "EmailPart" as
discriminator-value:
LOG: execute 000000000000004E: INSERT INTO
origo_email_part (entity_id, part_index, uid, VERSION,
message_id, parent_id, part_type)
VALUES ($1, $2, $3, $4, $5, $6, $7)
DETAIL: parameters: $1 = '286555', $2 = '1', $3 =
'fcaa0282-df46-4eed-8b0b-85ac647954eb', $4 = '1', $5 =
'402617', $6 = NULL, $7 = 'EmailPart'
This results in other errors as "singletype" is used as value
when EL tries to retrieve the entity.
It seems I must figure out why EL wants to insert
EmailPart.class as value instead of EmailSinglePart.class in
ObjectBuilder.descriptor.
_______________________________________________
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
