Partial insert statements being submitted with incorrect default values

[bobby.diaz]

It seems as though the InsertResolver is causing incorrect default values to be returned by the ResolverUtil due to the wrong element symbol being sent to the ResolverUtil.getDefault() method.  In the code below, taken from InsertResolver.getVariableValues(), I believe the first two rows inside the if statement should be reversed so that next.clone() is used to determine the default value rather than the varSymbol whose type has been changed to BOOLEAN.

        Collection<ElementSymbol> insertElmnts = ResolverUtil.resolveElementsInGroup(insert.getGroup(), metadata);
        insertElmnts.removeAll(insert.getVariables());

        Iterator<ElementSymbol> defaultIter = insertElmnts.iterator();
        while(defaultIter.hasNext()) {
            ElementSymbol next = defaultIter.next();
            ElementSymbol varSymbol = next.clone();
            varSymbol.getGroupSymbol().setName(ProcedureReservedWords.CHANGING);
            varSymbol.setType(DataTypeManager.DefaultDataClasses.BOOLEAN);
            result.put(varSymbol, new Constant(Boolean.FALSE));

            if (!changingOnly) {
                Expression value = ResolverUtil.getDefault(varSymbol, metadata);
                varSymbol = next.clone();
                varSymbol.getGroupSymbol().setName(SQLConstants.Reserved.NEW);
                result.put(varSymbol, value);
            }
        }

Is this a bug?  If so, is there a work around other than specifying all columns/values in the insert?

Regards,

Bobby

[shawkins]

Yes, this is a regression with TEIID-2222 which corrected the changing variable type, but inadvertently changed the type for the getDefault call.  Unfortunately this went unnoticed as the string conversion to boolean does not result in an exception and requires specific usage to see the incorrect value.  This will require a patch to fix.  Can you log an issue?

Thanks,

Steve

[bobby.diaz]

Logged as issue TEIID-2553

Regards,

Bobby

[shawkins]

Thanks again for spotting this.  The correction was made and will be in for 8.5.0.Alpha1 after the next merge from 8.4.x.

Steve