Seen with NB 6.1 with patch 4 and ojc IEP *.nbm files in build 20081006.

This particular issue relates specifically to CLOB removal, but I believe it points to the need to propagate schema
changes downstream to subsequent operators. 

There is another more general bug that deals more with schema changes that are visible in the property dialogs: issue
138304.

Following is an email exchange between myself and Philip Varghese that describes the issue and workarounds, and the
application is attached:

Philip Varghese wrote:
> Looked at the attached project and observed the following
> Most of the iep files have stale references to clob attributes in there respective .iep files, for example the
DeleteStreamInput.iep has for the operator TripleEventSize (TupleSerialCorrelation), the following schema property
>
>             <component type="/IEP/Metadata/ColumnMetadata" name="clob1_0" title="clob1_0">
>                 <property name="name" value="clob1_0"/>
>                 <property name="type" value="CLOB"/>
>             </component>
>
> Although the attribute is not present in the operator's attribute list when the operator dialog is opened. However
when i open the property dialog and press "OK" and then save the iep process (pressing OK marks the iep file as
changed), the stale CLOB attributes are removed.
>
> By going through the other iep files InsertStreamInput.iep, NotificationStreamInput.iep, RelationStreamInput.iep and
StreamInputInput.iep, opening/closing the operator dialogs and saving them i was able to remove all the stale references.
>
> This looks like a GUI limitation/bug.
>
> I am not sure, what are the actions/steps that you went through to delete the CLOB attribute, did you only remove the
CLOB attribute from the upstream InputStream operator?  

The above is exactly what I did. Since I couldn't see the CLOB references in the property dialogs for any subsequent
operator, I didn't think to "OK" in those dialogs! I looked at them to make sure the attribute deletions were
propagated, then canceled out of the dialog.

> or did you go through all the downstream operators and remove or replace them with varchar types?

I didn't need to keep the attribute in any other form, so I simply deleted it. The downstream operators did not show any
CLOB data type attributes.

> I think based on what actions where performed to change the CLOB, you can file a bug against the editor, just keep in
mind that there is an enhancement ticket that is open which states that any property changes to an operator in an iep
process does not automatically change the dependent operators downstream, which will not be addressed this release. The
workaround is that the user will have to open up the downstream operator's and make the changes.
>
> Even with this limitation, i don't think you will have to rewrite the tests from scratch, although the tedious work of
opening each iep operator and saving the iep file remains.
If someone can give me guidance as to what to delete from the *.iep text file, I can vary my tasks to minimize the
tedium. :)
>
> Thanks
> Philip
>
> Jennifer Lautz wrote:
>> I am hoping that I won't have to rewrite all my driver tests from scratch . . .
>>
>> I have a number of driver tests that specified CLOB attributes.
>>
>> In the IEP graphical editor property dialog for the StreamInput operator:
>> 1. I delete the CLOB attribute and save the  IEP process.
>> 2. I clean and rebuild the IEP project.
>> 3. I clean/build/deploy the composite application containing the IEP projects with the deleted CLOB attributes.
>> 4. I continue to get iepse deployment errors about CLOBs not being supported by a number of operators because of SQL
errors (at bottom).
>>
>> Questions:
>>
>> 1. Should simply deleting the CLOB attributes be sufficient to remove all traces of CLOB from an IEP process? Is it a
bug that deleting all CLOB attributes, that the *.iep and *.wsdl files still seem to contain CLOB information?
>> 2. What can I safely delete from the *.iep text files to completely get rid of any trace of CLOBs? -- I know that
*wsdl files can simply be deleted and regenerated.
>>
>> The test I'm writing/rewriting is attached.
>>
>> Samples errors from Glassfish server.log:
>>
>> [#|2008-10-07T18:08:29.517-0500|SEVERE|sun-appserver9.1|com.sun.jbi.engine.iep.c
>> ore.runtime.IEPEngine|_ThreadID=56;_ThreadName=NotificationStreamInput.Notificat
>> ionStreamInput_iep(RoundRobin-Scheduler);_RequestID=01f92abb-f4be-4085-9b11-d271
>> 14fc56e8;|IEPSEaga03010: Operator PassThrough fail to set up
>> java.sql.SQLSyntaxErrorException: Column 'T0.CLOB1' is either not in any table i
>> n the FROM list or appears within a join specification and is outside the scope
>> of the join specification or appears in a HAVING clause and is not in the GROUP
>> BY list. If this is a CREATE or ALTER TABLE  statement then 'T0.CLOB1' is not a
>> column in the target table.
>>        at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unkn
>> own Source)
>>        at org.apache.derby.client.am.SqlException.getSQLException(Unknown Sourc
>> e)
>>        at org.apache.derby.client.am.Connection.prepareStatement(Unknown Source
>> )
>>        at com.sun.gjc.spi.base.ConnectionHolder.prepareStatement(ConnectionHold
>> er.java:475)
>>        at com.sun.jbi.engine.iep.core.runtime.operator.impl.derby.TupleSerialCo
>> rrelationDerby.createOperateStatements(TupleSerialCorrelationDerby.java:125)
>>        at com.sun.jbi.engine.iep.core.runtime.operator.impl.TupleSerialCorrelat
>> ion.createOperateStmt(TupleSerialCorrelation.java:122)
>>        at com.sun.jbi.engine.iep.core.runtime.operator.impl.AbstractOperator.se
>> tRuntimeConnection(AbstractOperator.java:364)
>>        at com.sun.jbi.engine.iep.core.runtime.scheduler.RoundRobin.run(RoundRob
>> in.java:143)
>>        at java.lang.Thread.run(Thread.java:619)
>> Caused by: org.apache.derby.client.am.SqlException: Column 'T0.CLOB1' is either
>> not in any table in the FROM list or appears within a join specification and is
>> outside the scope of the join specification or appears in a HAVING clause and is
>> not in the GROUP BY list. If this is a CREATE or ALTER TABLE  statement then 'T
>> 0.CLOB1' is not a column in the target table.
>>        at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source)
>>        at org.apache.derby.client.net.NetStatementReply.parsePrepareError(Unkno
>> wn Source)
>>        at org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(Unk
>> nown Source)
>>        at org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutp
>> ut(Unknown Source)
>>        at org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(
>> Unknown Source)
>>        at org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(U
>> nknown Source)
>>        at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Unknow
>> n Source)
>>        at org.apache.derby.client.am.PreparedStatement.readPrepareDescribeInput
>> Output(Unknown Source)
>>        at org.apache.derby.client.am.PreparedStatement.flowPrepareDescribeInput
>> Output(Unknown Source)
>>        at org.apache.derby.client.am.PreparedStatement.prepare(Unknown Source)
>>        at org.apache.derby.client.am.Connection.prepareStatementX(Unknown Sourc
>> e)
>>        ... 7 more
>> |#]
>>
>> [#|2008-10-07T18:08:29.712-0500|SEVERE|sun-appserver9.1|com.sun.jbi.engine.iep.c
>> ore.runtime.IEPEngine|_ThreadID=55;_ThreadName=DeleteStreamInput.DeleteStreamInp
>> ut_iep(RoundRobin-Scheduler);_RequestID=d23b8664-21cb-4ed3-9594-cda76ee5bb71;|IE
>> PSEaga03010: Operator HalfSchemaDoubleSend3rd fail to set up
>> java.sql.SQLSyntaxErrorException: Column 'T0.CLOB1' is either not in any table i
>> n the FROM list or appears within a join specification and is outside the scope
>> of the join specification or appears in a HAVING clause and is not in the GROUP
>> BY list. If this is a CREATE or ALTER TABLE  statement then 'T0.CLOB1' is not a
>> column in the target table.
>>        at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unkn
>> own Source)
>>        at org.apache.derby.client.am.SqlException.getSQLException(Unknown Sourc
>> e)
>>        at org.apache.derby.client.am.Connection.prepareStatement(Unknown Source
>> )
>>        at com.sun.gjc.spi.base.ConnectionHolder.prepareStatement(ConnectionHold
>> er.java:475)
>>        at com.sun.jbi.engine.iep.core.runtime.operator.impl.derby.TupleSerialCo
>> rrelationDerby.createOperateStatements(TupleSerialCorrelationDerby.java:125)
>>        at com.sun.jbi.engine.iep.core.runtime.operator.impl.TupleSerialCorrelat
>> ion.createOperateStmt(TupleSerialCorrelation.java:122)
>>        at com.sun.jbi.engine.iep.core.runtime.operator.impl.AbstractOperator.se
>> tRuntimeConnection(AbstractOperator.java:364)
>>        at com.sun.jbi.engine.iep.core.runtime.scheduler.RoundRobin.run(RoundRob
>> in.java:143)
>>        at java.lang.Thread.run(Thread.java:619)
>> Caused by: org.apache.derby.client.am.SqlException: Column 'T0.CLOB1' is either
>> not in any table in the FROM list or appears within a join specification and is
>> outside the scope of the join specification or appears in a HAVING clause and is
>> not in the GROUP BY list. If this is a CREATE or ALTER TABLE  statement then 'T
>> 0.CLOB1' is not a column in the target table.
>>        at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source)
>>        at org.apache.derby.client.net.NetStatementReply.parsePrepareError(Unkno
>> wn Source)
>>        at org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(Unk
>> nown Source)
>>        at org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutp
>> ut(Unknown Source)
>>        at org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(
>> Unknown Source)
>>        at org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(U
>> nknown Source)
>>        at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Unknow
>> n Source)
>>        at org.apache.derby.client.am.PreparedStatement.readPrepareDescribeInput
>> Output(Unknown Source)
>>        at org.apache.derby.client.am.PreparedStatement.flowPrepareDescribeInput
>> Output(Unknown Source)
>>        at org.apache.derby.client.am.PreparedStatement.prepare(Unknown Source)
>>        at org.apache.derby.client.am.Connection.prepareStatementX(Unknown Sourc
>> e)
>>        ... 7 more
>> |#]