broken combatibility to 3.2: incompatible types error when compiling BasePeer classes

• Key: TORQUE-76
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Thomas Vandahl
• Reporter: Ronny Völker
• Component/s: Generator
• Affects Version/s: 3.3-RC1
• Fix Version/s: 3.3

Description

When compiling Scarab with Torque3.3rc1 lots of incompatible types error are returned.
When compiling with Torque3.2 everything is compiled successfully.

The root cause are changes of torque/templates/trunk/src/templates/om/Peer.vm in r373352.
In this revisions some class casts have been removed which seem to be required in BasePeer classes, if inheritance and interfaces are used in the schema mapping.

Sample compilation output:
    [javac] C:\elaxy\svn\scarab_trunk\src\java\org\tigris\scarab\om\BaseIssuePeer.java:933: incompatible types
    [javac] found : org.tigris.scarab.om.Module
    [javac] required: org.tigris.scarab.om.ScarabModule
    [javac] ScarabModule temp_obj2 = temp_obj1.getModule();
    
The buggy line using Torque3.3rc1 templates:
Issue temp_obj1 = (Issue) results.get(j);
ScarabModule temp_obj2 = temp_obj1.getModule();

The sameline using Torque3.2 templates:
Issue temp_obj1 = (Issue) results.get(j);
ScarabModule temp_obj2 = (ScarabModule)temp_obj1.getModule();

The interface of Issue.getModule() (inherited from BaseIssue):
    public Module getModule()

The related sections in the schema.xml of Scarab:
<table name="SCARAB_MODULE" idMethod="idbroker" javaName="ScarabModule"
    baseClass="org.tigris.scarab.om.AbstractScarabModule"
    interface="Module">
...
    
<table name="SCARAB_ISSUE" idMethod="idbroker" javaName="Issue">
...
    <column name="MODULE_ID" required="true" type="INTEGER"></column>

    <foreign-key foreignTable="SCARAB_MODULE">
        <reference local="MODULE_ID" foreign="MODULE_ID"/>
    </foreign-key>
...

Comments

Please note that the documentation of the "interface" attribute of the <table> element has changed to allow more generic use of interfaces. This may have an influence on the behaviour you observe.

Taking the changes back is not a real problem, but I'd like to avoid such things in the future. Could you please provide a stripped-down test case?

[Ronny Völker]

The attached zip contains some stripped down source files of scarab. They should be sufficient reproduce this bug. Please let me know, if something is missing.
(Sorry for my late answer, I was really short of time in the last days.)

[Thomas Vandahl]

Fixed in SVN. Ronny, would you please check out the latest trunk to make sure everything works ok?

[Ronny Völker]

Is there some kind of nightly build available, that can be downloaded?
I tried to compile the trunk from sources, but maven returns a lot of errors while downloading the dependencies and I could not yet figure out the reason for that.
As a workaround I replaced the changed *.vm files in torque-gen-templates-3.3-RC1.jar directly, but this did no work either: The generated Scarab-classes had compilation errors.