We've noticed a problem where, during object retrieval of an object with a class that is 2 levels derived from an abstract base class, DN displays the message:

[WARN ] 05:33:20.915 Retrieve - Found type=class com.sas.framework.BlahBlah but abstract and more than 1 concrete subclass ([com.sas.BlahLevel1Cls1, com.sas.BlahLevel1Cls2, com.sas.BlahLevel1Cls3]). Really you need a discriminator to help identifying the type. Choosing class com.sas.BlahLevel1Cls3

This was unexpected because:

• A discriminator is configured in the abstract base class
• A discriminator value is provided in each of the derived classes
• The list of concrete subclasses is only a small subset of the classes in the model
• It is only showing the list of subclasses immediately extending the abstract base class

Looking at PersistentClassROF#getObject we noticed that the call to getSubclassesForClass passes 'false' for the 'includeDescendants' parameter - which would prevent it from finding subclasses beyond the classes that immediately extend the abstract base class.

            String[] subclasses = this.ec.getMetaDataManager().getSubclassesForClass(pcClassForObject.getName(), false);

 Is this intentional? How will it ever find the full range of subclasses if this parameter is false?

I found the cause eventually!

This part of the error is possibly misleading:

Really you need a discriminator to help identifying the type

It seems to suggest that you need to use a discriminator (which we already are) so that could lead the developer to check their metadata etc.,

The real problem was that metadata was missing due to two package.jdo files being provided for the same package but having different classes in them - result of a split up/refactor that ended up reusing the same package name for different classes - some in the main app and some that were migrated to a shared library, hence at runtime two package.jdo files were present "in" the same package (same logical package but two separate package.jdo files).

The root cause was that the lookup of the class name using the discriminator value failed - because the metadata was not present.

Perhaps I can look at making the error a more accurate description of the cause - or maybe it needs two separate error messages:

1. One for when discriminator column is really not configured in the metadata
2. When discriminator column is configured in the metadata but the specific discriminator value could not be mapped to a known PC

Yes, make whatever error you see as explicit as possible to whatever situation you have. Since i've not had these things then the message was likely un-specific.

I have added a pull request - i created some two extra local booleans to help track the history because the message is constructed well after a null className is returned. These two booleans could probably be condensed into one.