Issue Details (XML | Word | Printable)

Key: NUCCORE-360
Type: Improvement Improvement
Status: Closed Closed
Resolution: Cannot Reproduce
Priority: Testcase Required Testcase Required
Assignee: Unassigned
Reporter: Yang ZHONG
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
DataNucleus Core

Inheritance Strategy specification isn't followed between InheritanceMetaData provision & consumption

Created: 13/Aug/09 08:06 PM   Updated: 05/Jul/11 01:06 PM   Resolved: 03/Feb/10 04:32 PM
Component/s: MetaData
Affects Version/s: 1.1.4, 1.1.5, 2.0.0.m1
Fix Version/s: None

Environment: Linux, Java 5

Forum Thread URL: HTTP://WWW.JPOx.org/servlet/forum/viewthread_thread,5640
Severity: Production


 Description  « Hide
JDO specification (2.2) has specified Inheritance Strategy can only be "new-table", "superclass-table" or "subclass-table". If not declared, "new-table" for base and "superclass-table" for subclass.

However, InheritanceMetaData#getStrategy() may return null, which is a bug by either InheritanceMetaData provision, or InheritanceMetaData consumption which doesn't interpret null as "new-table" for base and "superclass-table" for subclass.

Knowing the Test Case requirement, ones have been failed to reproduce the above problem. Reproducible in local environment whose 1000 or so JDOs can't be uploaded...

No matter InheritanceMetaData provision implementations, InheritanceMetaData consumption can always be improved to be more robust and prevent from this

java.lang.NullPointerException
at org.datanucleus.metadata.AbstractClassMetaData.applyDefaultDiscriminatorValueWhenNotSpecified(Abstra
ctClassMetaData.java:1407)
at org.datanucleus.metadata.ClassMetaData.populate(ClassMetaData.java:217)
at org.datanucleus.metadata.MetaDataManager$1.run(MetaDataManager.java:2317)

Only for the only purpose of Proof of Concept, the experiment of changing AbstractClassMetaData.getClassManagingTableForClass from

        else if (imd.getStrategy() == InheritanceStrategy.NEW_TABLE)
        {
            return cmd;
        }
        else if (imd.getStrategy() == InheritanceStrategy.SUPERCLASS_TABLE)
        {
            return getClassManagingTableForClass(cmd.getSuperAbstractClassMetaData());
        }

to

        final Object strategy = imd.getStrategy();
        if (strategy == InheritanceStrategy.NEW_TABLE)
        {
            return cmd;
        }
        
        final AbstractClassMetaData base = cmd.getSuperAbstractClassMetaData();
        if (strategy == InheritanceStrategy.SUPERCLASS_TABLE)
        {
            return getClassManagingTableForClass(base);
        }
        if (strategy == null)
        {
            return base == null ? cmd : getClassManagingTableForClass(base);
        }

has solved the problem.

Thanks.

Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 13/Aug/09 08:31 PM
Automatic issue downgrading when users don't bother providing testcases.
Things can be marked as "Blocker" all they want but there is no way something is addressable until they tackle this basic point.

Yang ZHONG added a comment - 15/Oct/09 04:43 PM
Same fix is also applicable to 1.1.6.

Andy Jefferson added a comment - 03/Feb/10 04:32 PM
Attach the long awaited testcase here if you write one, otherwise nothing to do here.

Zied Hamdi added a comment - 04/Jul/11 03:57 PM
Hi Yang and Andy,

@Yang thanks for submitting this issue

@Andy: there's a NullPointer trace, I think this shouldn't occur in any mature project : the exception must be explicit, I suggest you add a more explicit exception if you find a null value rather than just closing the bug and doing nothing (this won't make things evolve)

I have the same issue that disappeared when I've removed the explicit annotation @Inheritance(strategy = InheritanceType.SINGLE_TABLE)


My test case is basic

@RooJavaBean
@RooToString
@RooEntity
@MappedSuperclass
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
public abstract class PersonProperty {
@ManyToOne
private Person person;

private String strValue;
//...
}


@RooJavaBean
@RooToString
@RooEntity
public class EMail extends PersonProperty {
}

Best Regards,
Zied Hamdi

Andy Jefferson added a comment - 04/Jul/11 04:18 PM
@Zied, DataNucleus problem reporting policy has been in place since 2008 at project inception, as per
http://www.datanucleus.org/project/problem_reporting.html
The onus is on people to demonstrate problems. In the same way the onus is on you to demonstrate your problem with a valid testcase as per that link (and that doesn't allow any ROO artifacts). And no I see no NullPointer trace anywhere here in this report. Maybe you have one there but currently its a secret.

Failure to demonstrate on behalf of the user, and lack of resource here, means that any unreproduceable problem will not be left open indefinitely. If you don't like that then that's a shame, but people always have the opportunity to contribute (aka open source project), just like Yang Zhong and his company (IBM) had (and failed to do)

Zied Hamdi added a comment - 04/Jul/11 04:45 PM
@Andy the Null pointer trace is in the bug description, I don't see the point of adding it in every comment, I found this bug page thanks to that same trace.

I understand that it is frustrating for you to be in lack of resources but I don't think it's a good reason to react like that on posts where people took the time to submit a bug. If you want to be radical and follow the rules exactly as written in the policy of 2008, let's say it's your freedom. I just find it's a pitty to represent a good project with this kind of reactions because it won't encourage people to submit bugs and it doesn't help the project in any way.

p.s: I don't think IBM is in "competition" with you


Zied Hamdi added a comment - 05/Jul/11 01:06 PM