Bug 1146207

Fix is ready to be committed - only problem is that it will require an increase to the RTGOV_ACTIVITY_PROPERTIES 'value' column, as during testing I got:

Caused by: org.h2.jdbc.JdbcSQLException: Value too long for column "VALUE VARCHAR(255)": "'{""org.switchyard.messageId"":""ID-gbrown-redhat-46259-1411634329007-0-1"",""Accept/format"":""text"",""{http://www.projectoverlord.io/e... (628)"; SQL statement:
insert into RTGOV_ACTIVITY_PROPERTIES (unitId, unitIndex, name, value) values (?, ?, ?, ?) [22001-168]


How should db schema changes be handled - should I define the new length in the code and a new schema is generated, and we provide instructions for manually updating existing dbs?

(In reply to Gary Brown from comment #5)
> Fix is ready to be committed - only problem is that it will require an
> increase to the RTGOV_ACTIVITY_PROPERTIES 'value' column, as during testing
> I got:
> 
> Caused by: org.h2.jdbc.JdbcSQLException: Value too long for column "VALUE
> VARCHAR(255)":
> "'{""org.switchyard.messageId"":""ID-gbrown-redhat-46259-1411634329007-0-1"",
> ""Accept/format"":""text"",""{http://www.projectoverlord.io/e... (628)"; SQL
> statement:
> insert into RTGOV_ACTIVITY_PROPERTIES (unitId, unitIndex, name, value)
> values (?, ?, ?, ?) [22001-168]
> 
> 
> How should db schema changes be handled - should I define the new length in
> the code and a new schema is generated, and we provide instructions for
> manually updating existing dbs?

We could let the new schema be generated and then work out the diff between the old and new schema.  The schema update could then be supplied as SQL file containing a number of "alter ..." statements to get the schema to match the new code annotations.  The hibernate validation might complain if it doesn't find schema that matches the code annotations. Instructions also supplied for manually updating the existing db as we currently don't have an installer to apply database patches to live production data.

Question: What is the likely max size of value attribute?  If this is/could be open ended would the attribute be better off annotated with @Lob to map to database large object types?

(In reply to Steve Johnson from comment #6)
> (In reply to Gary Brown from comment #5)
> > Fix is ready to be committed - only problem is that it will require an
> > increase to the RTGOV_ACTIVITY_PROPERTIES 'value' column, as during testing
> > I got:
> > 
> > Caused by: org.h2.jdbc.JdbcSQLException: Value too long for column "VALUE
> > VARCHAR(255)":
> > "'{""org.switchyard.messageId"":""ID-gbrown-redhat-46259-1411634329007-0-1"",
> > ""Accept/format"":""text"",""{http://www.projectoverlord.io/e... (628)"; SQL
> > statement:
> > insert into RTGOV_ACTIVITY_PROPERTIES (unitId, unitIndex, name, value)
> > values (?, ?, ?, ?) [22001-168]
> > 
> > 
> > How should db schema changes be handled - should I define the new length in
> > the code and a new schema is generated, and we provide instructions for
> > manually updating existing dbs?

Will work with Gary to find a length that does not break any of our supported databases.

Created attachment 942234 [details]
Updated version of the rtgov ordermgmt quickstart

To test the fix (once BZ1146205 patch has been applied, and also with the latest rtgov-ui from community), deploy the updated ordermgmt quickstart (three modules now instead of two).

Then from within the ordermgmt/app submit the order5bad message (e.g. mvn exec:java -Dreq=order5bad).

This will result in a xml schema issue being reported in a situation. Go to the message associated with that situation and fix the message (change 'customerx' element to 'customer') and resubmit.

When resubmitted, check the FSW console and you should see "ORDER EXAMPLE HEADER: [m:ExampleHeaderValue: null]" which indicates that the header value has been returned as a dom.

This product has been discontinued or is no longer tracked in Red Hat Bugzilla.