Re: [Continumm 1.0.3] Alot of errors in the continumm log file..
continuum.mdo is used for classes and package.jdo generation If you modify only the field length, classes will be the same. I'm not sure our package.jdo generator support column jdbc-type defintion. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, Took a quick look at the package.jdo and it only contains the length property for the column not the actual datatyp. Isn't the SCMResult.class (found in continuum-model.jar) generated from http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-model/src/main/mdo/continuum.mdo This file contains the datatypes and length for the columns. And in that case the continuum.mdo needs to be modified and the class re-generated, or? /Mattias ok, I'll try changing that when I find some spare time. And the create table stmt should look like this and nothing else. CREATE TABLE SCMRESULT2 ( SCMRESULT_ID BIGINT PRIMARY KEY not null, COMMAND_LINE VARCHAR(255), COMMAND_OUTPUT CLOB(16M), EXCEPTION VARCHAR(8192), PROVIDER_MESSAGE VARCHAR(1024), SUCCESS CHAR(1) not null, MODEL_ENCODING VARCHAR(255) ); /Mattias oh yes, you need to change package.jdo in continuum-model.jar I don't think you need to change something else. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, Is blob really appropriate for varchar type of information? You can't copy varchar into a blob! Shouldn't it be a clob? Below are the SQL statments that I executed. (unfortunatly you can't alter the data type of the column directly). But when I started continumm it complained that the column COMMAND_OUTPUT should be a VARCHAR and not a CLOB. org.jpox.store.exceptions.IncompatibleDataTypeException: Incompatible data type for column SCMRESULT.COMMAND_OUTPUT : was Types.CLOB, but type expected was Types.VARCHAR. Please check that the type in the datastore and the type specified in the MetaData are consistent. So I guess you can't change this without changing to code. Or is the meta data available some where? Regards, Mattias CREATE TABLE SCMRESULT2 ( SCMRESULT_ID BIGINT PRIMARY KEY not null, COMMAND_LINE VARCHAR(255), COMMAND_OUTPUT VARCHAR(16384), EXCEPTION VARCHAR(8192), PROVIDER_MESSAGE VARCHAR(1024), SUCCESS CHAR(1) not null, MODEL_ENCODING VARCHAR(255) ); INSERT INTO SCMRESULT2 SELECT * FROM SCMRESULT; ALTER TABLE CHANGESET DROP CONSTRAINT CHANGESET_FK1; ALTER TABLE BUILDRESULT DROP CONSTRAINT BUILDRESULT_FK1; ALTER TABLE BUILDRESULT DROP CONSTRAINT BUILDRESULT_FK3; ALTER TABLE PROJECT DROP CONSTRAINT PROJECT_FK1; ALTER TABLE PROJECT DROP CONSTRAINT PROJECT_FK4; DROP TABLE SCMRESULT; RENAME TABLE SCMRESULT2 TO SCMRESULT; ALTER TABLE CHANGESET ADD CONSTRAINT CHANGESET_FK1 FOREIGN KEY (CHANGES_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE BUILDRESULT ADD CONSTRAINT BUILDRESULT_FK1 FOREIGN KEY (SCM_RESULT_SCMRESULT_ID_VM) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE BUILDRESULT ADD CONSTRAINT BUILDRESULT_FK3 FOREIGN KEY (SCM_RESULT_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_FK1 FOREIGN KEY (CHECKOUT_RESULT_SCMRESUL2U) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_FK4 FOREIGN KEY (CHECKOUT_RESULT_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); If you change it, can you send us the procedure? we'll add an entry in faqs. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, ok, I'll try to change the column. Thanks for the quick response! Regards, Mattias It's a known problem thazt we'll fix in 1.1. The length of a field (COMMAND_OUTPUT) isn't enought in database, you can change it to a blob with a sql client like squirrel. Emmanuel Mattias Andersson a écrit : Hi, I got some errors today in the continuum log fil that I do know how to solve? The appeared when I pressed the build button for a project. It's a shell project, SCM is CVS and I use continumm 1.0.3. Are these errors known or should I add new isues? And are there any workarounds? (the complete stack trace is not included below to keep the mail smaller. They are available if needed) Regards, Mattias ERROR 1: === cvs update: move away scripts/Database/mssql/Views/dbo.DB_SubRatParamHistory_1.VIW; it is in the way 31802313 [Thread-2] WARN org.apache.maven.continuum.scm.ContinuumScm - Provider message: The cvs command failed. 31802391 [Thread-2] ERROR org.apache.maven.continuum.buildcontroller.BuildController - Error while building project. javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO SCMRESULT (SCMRESULT_ID,SUCCESS,COMMAND_OUTPUT,EXCEPTION,COMMAND_LINE,PROVIDER_MESSAGE,MODEL_ENCODING) VALUES (?,?,?,?,?,?,?) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:387) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2146) at org.jpox.store.StoreManager.insert(StoreManager.java:739)
Re: [Continumm 1.0.3] Alot of errors in the continumm log file..
Hi, Will it really help to change the length field in package.jdo? I don't think so since I changed datatyp from a varchar to a CLOB. And when starting continuum it complained that the datatype changed. Anyway I don't have time to do more about this right now. I'll wait for 1.1 Regards, Mattias continuum.mdo is used for classes and package.jdo generation If you modify only the field length, classes will be the same. I'm not sure our package.jdo generator support column jdbc-type defintion. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, Took a quick look at the package.jdo and it only contains the length property for the column not the actual datatyp. Isn't the SCMResult.class (found in continuum-model.jar) generated from http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-model/src/main/mdo/continuum.mdo This file contains the datatypes and length for the columns. And in that case the continuum.mdo needs to be modified and the class re-generated, or? /Mattias ok, I'll try changing that when I find some spare time. And the create table stmt should look like this and nothing else. CREATE TABLE SCMRESULT2 ( SCMRESULT_ID BIGINT PRIMARY KEY not null, COMMAND_LINE VARCHAR(255), COMMAND_OUTPUT CLOB(16M), EXCEPTION VARCHAR(8192), PROVIDER_MESSAGE VARCHAR(1024), SUCCESS CHAR(1) not null, MODEL_ENCODING VARCHAR(255) ); /Mattias oh yes, you need to change package.jdo in continuum-model.jar I don't think you need to change something else. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, Is blob really appropriate for varchar type of information? You can't copy varchar into a blob! Shouldn't it be a clob? Below are the SQL statments that I executed. (unfortunatly you can't alter the data type of the column directly). But when I started continumm it complained that the column COMMAND_OUTPUT should be a VARCHAR and not a CLOB. org.jpox.store.exceptions.IncompatibleDataTypeException: Incompatible data type for column SCMRESULT.COMMAND_OUTPUT : was Types.CLOB, but type expected was Types.VARCHAR. Please check that the type in the datastore and the type specified in the MetaData are consistent. So I guess you can't change this without changing to code. Or is the meta data available some where? Regards, Mattias CREATE TABLE SCMRESULT2 ( SCMRESULT_ID BIGINT PRIMARY KEY not null, COMMAND_LINE VARCHAR(255), COMMAND_OUTPUT VARCHAR(16384), EXCEPTION VARCHAR(8192), PROVIDER_MESSAGE VARCHAR(1024), SUCCESS CHAR(1) not null, MODEL_ENCODING VARCHAR(255) ); INSERT INTO SCMRESULT2 SELECT * FROM SCMRESULT; ALTER TABLE CHANGESET DROP CONSTRAINT CHANGESET_FK1; ALTER TABLE BUILDRESULT DROP CONSTRAINT BUILDRESULT_FK1; ALTER TABLE BUILDRESULT DROP CONSTRAINT BUILDRESULT_FK3; ALTER TABLE PROJECT DROP CONSTRAINT PROJECT_FK1; ALTER TABLE PROJECT DROP CONSTRAINT PROJECT_FK4; DROP TABLE SCMRESULT; RENAME TABLE SCMRESULT2 TO SCMRESULT; ALTER TABLE CHANGESET ADD CONSTRAINT CHANGESET_FK1 FOREIGN KEY (CHANGES_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE BUILDRESULT ADD CONSTRAINT BUILDRESULT_FK1 FOREIGN KEY (SCM_RESULT_SCMRESULT_ID_VM) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE BUILDRESULT ADD CONSTRAINT BUILDRESULT_FK3 FOREIGN KEY (SCM_RESULT_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_FK1 FOREIGN KEY (CHECKOUT_RESULT_SCMRESUL2U) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_FK4 FOREIGN KEY (CHECKOUT_RESULT_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); If you change it, can you send us the procedure? we'll add an entry in faqs. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, ok, I'll try to change the column. Thanks for the quick response! Regards, Mattias It's a known problem thazt we'll fix in 1.1. The length of a field (COMMAND_OUTPUT) isn't enought in database, you can change it to a blob with a sql client like squirrel. Emmanuel Mattias Andersson a écrit : Hi, I got some errors today in the continuum log fil that I do know how to solve? The appeared when I pressed the build button for a project. It's a shell project, SCM is CVS and I use continumm 1.0.3. Are these errors known or should I add new isues? And are there any workarounds? (the complete stack trace is not included below to keep the mail smaller. They are available if needed) Regards, Mattias ERROR 1: === cvs update: move away scripts/Database/mssql/Views/dbo.DB_SubRatParamHistory_1.VIW; it is in the way 31802313 [Thread-2] WARN org.apache.maven.continuum.scm.ContinuumScm - Provider message: The cvs command failed. 31802391 [Thread-2] ERROR org.apache.maven.continuum.buildcontroller.BuildController - Error while building
Re: [Continumm 1.0.3] Alot of errors in the continumm log file..
Hi Emmanuel, Took a quick look at the package.jdo and it only contains the length property for the column not the actual datatyp. Isn't the SCMResult.class (found in continuum-model.jar) generated from http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-model/src/main/mdo/continuum.mdo This file contains the datatypes and length for the columns. And in that case the continuum.mdo needs to be modified and the class re-generated, or? /Mattias ok, I'll try changing that when I find some spare time. And the create table stmt should look like this and nothing else. CREATE TABLE SCMRESULT2 ( SCMRESULT_ID BIGINT PRIMARY KEY not null, COMMAND_LINE VARCHAR(255), COMMAND_OUTPUT CLOB(16M), EXCEPTION VARCHAR(8192), PROVIDER_MESSAGE VARCHAR(1024), SUCCESS CHAR(1) not null, MODEL_ENCODING VARCHAR(255) ); /Mattias oh yes, you need to change package.jdo in continuum-model.jar I don't think you need to change something else. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, Is blob really appropriate for varchar type of information? You can't copy varchar into a blob! Shouldn't it be a clob? Below are the SQL statments that I executed. (unfortunatly you can't alter the data type of the column directly). But when I started continumm it complained that the column COMMAND_OUTPUT should be a VARCHAR and not a CLOB. org.jpox.store.exceptions.IncompatibleDataTypeException: Incompatible data type for column SCMRESULT.COMMAND_OUTPUT : was Types.CLOB, but type expected was Types.VARCHAR. Please check that the type in the datastore and the type specified in the MetaData are consistent. So I guess you can't change this without changing to code. Or is the meta data available some where? Regards, Mattias CREATE TABLE SCMRESULT2 ( SCMRESULT_ID BIGINT PRIMARY KEY not null, COMMAND_LINE VARCHAR(255), COMMAND_OUTPUT VARCHAR(16384), EXCEPTION VARCHAR(8192), PROVIDER_MESSAGE VARCHAR(1024), SUCCESS CHAR(1) not null, MODEL_ENCODING VARCHAR(255) ); INSERT INTO SCMRESULT2 SELECT * FROM SCMRESULT; ALTER TABLE CHANGESET DROP CONSTRAINT CHANGESET_FK1; ALTER TABLE BUILDRESULT DROP CONSTRAINT BUILDRESULT_FK1; ALTER TABLE BUILDRESULT DROP CONSTRAINT BUILDRESULT_FK3; ALTER TABLE PROJECT DROP CONSTRAINT PROJECT_FK1; ALTER TABLE PROJECT DROP CONSTRAINT PROJECT_FK4; DROP TABLE SCMRESULT; RENAME TABLE SCMRESULT2 TO SCMRESULT; ALTER TABLE CHANGESET ADD CONSTRAINT CHANGESET_FK1 FOREIGN KEY (CHANGES_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE BUILDRESULT ADD CONSTRAINT BUILDRESULT_FK1 FOREIGN KEY (SCM_RESULT_SCMRESULT_ID_VM) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE BUILDRESULT ADD CONSTRAINT BUILDRESULT_FK3 FOREIGN KEY (SCM_RESULT_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_FK1 FOREIGN KEY (CHECKOUT_RESULT_SCMRESUL2U) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_FK4 FOREIGN KEY (CHECKOUT_RESULT_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); If you change it, can you send us the procedure? we'll add an entry in faqs. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, ok, I'll try to change the column. Thanks for the quick response! Regards, Mattias It's a known problem thazt we'll fix in 1.1. The length of a field (COMMAND_OUTPUT) isn't enought in database, you can change it to a blob with a sql client like squirrel. Emmanuel Mattias Andersson a écrit : Hi, I got some errors today in the continuum log fil that I do know how to solve? The appeared when I pressed the build button for a project. It's a shell project, SCM is CVS and I use continumm 1.0.3. Are these errors known or should I add new isues? And are there any workarounds? (the complete stack trace is not included below to keep the mail smaller. They are available if needed) Regards, Mattias ERROR 1: === cvs update: move away scripts/Database/mssql/Views/dbo.DB_SubRatParamHistory_1.VIW; it is in the way 31802313 [Thread-2] WARN org.apache.maven.continuum.scm.ContinuumScm - Provider message: The cvs command failed. 31802391 [Thread-2] ERROR org.apache.maven.continuum.buildcontroller.BuildController - Error while building project. javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO SCMRESULT (SCMRESULT_ID,SUCCESS,COMMAND_OUTPUT,EXCEPTION,COMMAND_LINE,PROVIDER_MESSAGE,MODEL_ENCODING) VALUES (?,?,?,?,?,?,?) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:387) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2146) at org.jpox.store.StoreManager.insert(StoreManager.java:739) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3415) at
Re: [Continumm 1.0.3] Alot of errors in the continumm log file..
Hi Emmanuel, Is blob really appropriate for varchar type of information? You can't copy varchar into a blob! Shouldn't it be a clob? Below are the SQL statments that I executed. (unfortunatly you can't alter the data type of the column directly). But when I started continumm it complained that the column COMMAND_OUTPUT should be a VARCHAR and not a CLOB. org.jpox.store.exceptions.IncompatibleDataTypeException: Incompatible data type for column SCMRESULT.COMMAND_OUTPUT : was Types.CLOB, but type expected was Types.VARCHAR. Please check that the type in the datastore and the type specified in the MetaData are consistent. So I guess you can't change this without changing to code. Or is the meta data available some where? Regards, Mattias CREATE TABLE SCMRESULT2 ( SCMRESULT_ID BIGINT PRIMARY KEY not null, COMMAND_LINE VARCHAR(255), COMMAND_OUTPUT VARCHAR(16384), EXCEPTION VARCHAR(8192), PROVIDER_MESSAGE VARCHAR(1024), SUCCESS CHAR(1) not null, MODEL_ENCODING VARCHAR(255) ); INSERT INTO SCMRESULT2 SELECT * FROM SCMRESULT; ALTER TABLE CHANGESET DROP CONSTRAINT CHANGESET_FK1; ALTER TABLE BUILDRESULT DROP CONSTRAINT BUILDRESULT_FK1; ALTER TABLE BUILDRESULT DROP CONSTRAINT BUILDRESULT_FK3; ALTER TABLE PROJECT DROP CONSTRAINT PROJECT_FK1; ALTER TABLE PROJECT DROP CONSTRAINT PROJECT_FK4; DROP TABLE SCMRESULT; RENAME TABLE SCMRESULT2 TO SCMRESULT; ALTER TABLE CHANGESET ADD CONSTRAINT CHANGESET_FK1 FOREIGN KEY (CHANGES_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE BUILDRESULT ADD CONSTRAINT BUILDRESULT_FK1 FOREIGN KEY (SCM_RESULT_SCMRESULT_ID_VM) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE BUILDRESULT ADD CONSTRAINT BUILDRESULT_FK3 FOREIGN KEY (SCM_RESULT_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_FK1 FOREIGN KEY (CHECKOUT_RESULT_SCMRESUL2U) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_FK4 FOREIGN KEY (CHECKOUT_RESULT_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); If you change it, can you send us the procedure? we'll add an entry in faqs. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, ok, I'll try to change the column. Thanks for the quick response! Regards, Mattias It's a known problem thazt we'll fix in 1.1. The length of a field (COMMAND_OUTPUT) isn't enought in database, you can change it to a blob with a sql client like squirrel. Emmanuel Mattias Andersson a écrit : Hi, I got some errors today in the continuum log fil that I do know how to solve? The appeared when I pressed the build button for a project. It's a shell project, SCM is CVS and I use continumm 1.0.3. Are these errors known or should I add new isues? And are there any workarounds? (the complete stack trace is not included below to keep the mail smaller. They are available if needed) Regards, Mattias ERROR 1: === cvs update: move away scripts/Database/mssql/Views/dbo.DB_SubRatParamHistory_1.VIW; it is in the way 31802313 [Thread-2] WARN org.apache.maven.continuum.scm.ContinuumScm - Provider message: The cvs command failed. 31802391 [Thread-2] ERROR org.apache.maven.continuum.buildcontroller.BuildController - Error while building project. javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO SCMRESULT (SCMRESULT_ID,SUCCESS,COMMAND_OUTPUT,EXCEPTION,COMMAND_LINE,PROVIDER_MESSAGE,MODEL_ENCODING) VALUES (?,?,?,?,?,?,?) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:387) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2146) at org.jpox.store.StoreManager.insert(StoreManager.java:739) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3415) at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3388) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1146) at org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1187) at org.jpox.store.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:409) at org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeObjectField(ParameterSetter.java:132) at org.jpox.state.StateManagerImpl.providedObjectField(StateManagerImpl.java:2627) ... ... ERROR 2: === ERROR 22001: A truncation error was encountered trying to shrink VARCHAR 'cvs update: move away scripts/Database/factorydata/CUSTOMER_' to length 1024. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.types.SQLChar.hasNonBlankChars(Unknown Source) at org.apache.derby.iapi.types.SQLVarchar.normalize(Unknown Source) at org.apache.derby.iapi.types.SQLVarchar.normalize(Unknown Source)
Re: [Continumm 1.0.3] Alot of errors in the continumm log file..
oh yes, you need to change package.jdo in continuum-model.jar I don't think you need to change something else. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, Is blob really appropriate for varchar type of information? You can't copy varchar into a blob! Shouldn't it be a clob? Below are the SQL statments that I executed. (unfortunatly you can't alter the data type of the column directly). But when I started continumm it complained that the column COMMAND_OUTPUT should be a VARCHAR and not a CLOB. org.jpox.store.exceptions.IncompatibleDataTypeException: Incompatible data type for column SCMRESULT.COMMAND_OUTPUT : was Types.CLOB, but type expected was Types.VARCHAR. Please check that the type in the datastore and the type specified in the MetaData are consistent. So I guess you can't change this without changing to code. Or is the meta data available some where? Regards, Mattias CREATE TABLE SCMRESULT2 ( SCMRESULT_ID BIGINT PRIMARY KEY not null, COMMAND_LINE VARCHAR(255), COMMAND_OUTPUT VARCHAR(16384), EXCEPTION VARCHAR(8192), PROVIDER_MESSAGE VARCHAR(1024), SUCCESS CHAR(1) not null, MODEL_ENCODING VARCHAR(255) ); INSERT INTO SCMRESULT2 SELECT * FROM SCMRESULT; ALTER TABLE CHANGESET DROP CONSTRAINT CHANGESET_FK1; ALTER TABLE BUILDRESULT DROP CONSTRAINT BUILDRESULT_FK1; ALTER TABLE BUILDRESULT DROP CONSTRAINT BUILDRESULT_FK3; ALTER TABLE PROJECT DROP CONSTRAINT PROJECT_FK1; ALTER TABLE PROJECT DROP CONSTRAINT PROJECT_FK4; DROP TABLE SCMRESULT; RENAME TABLE SCMRESULT2 TO SCMRESULT; ALTER TABLE CHANGESET ADD CONSTRAINT CHANGESET_FK1 FOREIGN KEY (CHANGES_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE BUILDRESULT ADD CONSTRAINT BUILDRESULT_FK1 FOREIGN KEY (SCM_RESULT_SCMRESULT_ID_VM) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE BUILDRESULT ADD CONSTRAINT BUILDRESULT_FK3 FOREIGN KEY (SCM_RESULT_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_FK1 FOREIGN KEY (CHECKOUT_RESULT_SCMRESUL2U) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_FK4 FOREIGN KEY (CHECKOUT_RESULT_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); If you change it, can you send us the procedure? we'll add an entry in faqs. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, ok, I'll try to change the column. Thanks for the quick response! Regards, Mattias It's a known problem thazt we'll fix in 1.1. The length of a field (COMMAND_OUTPUT) isn't enought in database, you can change it to a blob with a sql client like squirrel. Emmanuel Mattias Andersson a écrit : Hi, I got some errors today in the continuum log fil that I do know how to solve? The appeared when I pressed the build button for a project. It's a shell project, SCM is CVS and I use continumm 1.0.3. Are these errors known or should I add new isues? And are there any workarounds? (the complete stack trace is not included below to keep the mail smaller. They are available if needed) Regards, Mattias ERROR 1: === cvs update: move away scripts/Database/mssql/Views/dbo.DB_SubRatParamHistory_1.VIW; it is in the way 31802313 [Thread-2] WARN org.apache.maven.continuum.scm.ContinuumScm - Provider message: The cvs command failed. 31802391 [Thread-2] ERROR org.apache.maven.continuum.buildcontroller.BuildController - Error while building project. javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO SCMRESULT (SCMRESULT_ID,SUCCESS,COMMAND_OUTPUT,EXCEPTION,COMMAND_LINE,PROVIDER_MESSAGE,MODEL_ENCODING) VALUES (?,?,?,?,?,?,?) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:387) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2146) at org.jpox.store.StoreManager.insert(StoreManager.java:739) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3415) at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3388) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1146) at org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1187) at org.jpox.store.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:409) at org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeObjectField(ParameterSetter.java:132) at org.jpox.state.StateManagerImpl.providedObjectField(StateManagerImpl.java:2627) ... ... ERROR 2: === ERROR 22001: A truncation error was encountered trying to shrink VARCHAR 'cvs update: move away scripts/Database/factorydata/CUSTOMER_' to length 1024. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.types.SQLChar.hasNonBlankChars(Unknown Source)
Re: [Continumm 1.0.3] Alot of errors in the continumm log file..
ok, I'll try changing that when I find some spare time. And the create table stmt should look like this and nothing else. CREATE TABLE SCMRESULT2 ( SCMRESULT_ID BIGINT PRIMARY KEY not null, COMMAND_LINE VARCHAR(255), COMMAND_OUTPUT CLOB(16M), EXCEPTION VARCHAR(8192), PROVIDER_MESSAGE VARCHAR(1024), SUCCESS CHAR(1) not null, MODEL_ENCODING VARCHAR(255) ); /Mattias oh yes, you need to change package.jdo in continuum-model.jar I don't think you need to change something else. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, Is blob really appropriate for varchar type of information? You can't copy varchar into a blob! Shouldn't it be a clob? Below are the SQL statments that I executed. (unfortunatly you can't alter the data type of the column directly). But when I started continumm it complained that the column COMMAND_OUTPUT should be a VARCHAR and not a CLOB. org.jpox.store.exceptions.IncompatibleDataTypeException: Incompatible data type for column SCMRESULT.COMMAND_OUTPUT : was Types.CLOB, but type expected was Types.VARCHAR. Please check that the type in the datastore and the type specified in the MetaData are consistent. So I guess you can't change this without changing to code. Or is the meta data available some where? Regards, Mattias CREATE TABLE SCMRESULT2 ( SCMRESULT_ID BIGINT PRIMARY KEY not null, COMMAND_LINE VARCHAR(255), COMMAND_OUTPUT VARCHAR(16384), EXCEPTION VARCHAR(8192), PROVIDER_MESSAGE VARCHAR(1024), SUCCESS CHAR(1) not null, MODEL_ENCODING VARCHAR(255) ); INSERT INTO SCMRESULT2 SELECT * FROM SCMRESULT; ALTER TABLE CHANGESET DROP CONSTRAINT CHANGESET_FK1; ALTER TABLE BUILDRESULT DROP CONSTRAINT BUILDRESULT_FK1; ALTER TABLE BUILDRESULT DROP CONSTRAINT BUILDRESULT_FK3; ALTER TABLE PROJECT DROP CONSTRAINT PROJECT_FK1; ALTER TABLE PROJECT DROP CONSTRAINT PROJECT_FK4; DROP TABLE SCMRESULT; RENAME TABLE SCMRESULT2 TO SCMRESULT; ALTER TABLE CHANGESET ADD CONSTRAINT CHANGESET_FK1 FOREIGN KEY (CHANGES_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE BUILDRESULT ADD CONSTRAINT BUILDRESULT_FK1 FOREIGN KEY (SCM_RESULT_SCMRESULT_ID_VM) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE BUILDRESULT ADD CONSTRAINT BUILDRESULT_FK3 FOREIGN KEY (SCM_RESULT_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_FK1 FOREIGN KEY (CHECKOUT_RESULT_SCMRESUL2U) REFERENCES SCMRESULT(SCMRESULT_ID); ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_FK4 FOREIGN KEY (CHECKOUT_RESULT_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID); If you change it, can you send us the procedure? we'll add an entry in faqs. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, ok, I'll try to change the column. Thanks for the quick response! Regards, Mattias It's a known problem thazt we'll fix in 1.1. The length of a field (COMMAND_OUTPUT) isn't enought in database, you can change it to a blob with a sql client like squirrel. Emmanuel Mattias Andersson a écrit : Hi, I got some errors today in the continuum log fil that I do know how to solve? The appeared when I pressed the build button for a project. It's a shell project, SCM is CVS and I use continumm 1.0.3. Are these errors known or should I add new isues? And are there any workarounds? (the complete stack trace is not included below to keep the mail smaller. They are available if needed) Regards, Mattias ERROR 1: === cvs update: move away scripts/Database/mssql/Views/dbo.DB_SubRatParamHistory_1.VIW; it is in the way 31802313 [Thread-2] WARN org.apache.maven.continuum.scm.ContinuumScm - Provider message: The cvs command failed. 31802391 [Thread-2] ERROR org.apache.maven.continuum.buildcontroller.BuildController - Error while building project. javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO SCMRESULT (SCMRESULT_ID,SUCCESS,COMMAND_OUTPUT,EXCEPTION,COMMAND_LINE,PROVIDER_MESSAGE,MODEL_ENCODING) VALUES (?,?,?,?,?,?,?) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:387) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2146) at org.jpox.store.StoreManager.insert(StoreManager.java:739) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3415) at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3388) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1146) at org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1187) at org.jpox.store.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:409) at org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeObjectField(ParameterSetter.java:132) at
Re: [Continumm 1.0.3] Alot of errors in the continumm log file..
It's a known problem thazt we'll fix in 1.1. The length of a field (COMMAND_OUTPUT) isn't enought in database, you can change it to a blob with a sql client like squirrel. Emmanuel Mattias Andersson a écrit : Hi, I got some errors today in the continuum log fil that I do know how to solve? The appeared when I pressed the build button for a project. It's a shell project, SCM is CVS and I use continumm 1.0.3. Are these errors known or should I add new isues? And are there any workarounds? (the complete stack trace is not included below to keep the mail smaller. They are available if needed) Regards, Mattias ERROR 1: === cvs update: move away scripts/Database/mssql/Views/dbo.DB_SubRatParamHistory_1.VIW; it is in the way 31802313 [Thread-2] WARN org.apache.maven.continuum.scm.ContinuumScm - Provider message: The cvs command failed. 31802391 [Thread-2] ERROR org.apache.maven.continuum.buildcontroller.BuildController - Error while building project. javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO SCMRESULT (SCMRESULT_ID,SUCCESS,COMMAND_OUTPUT,EXCEPTION,COMMAND_LINE,PROVIDER_MESSAGE,MODEL_ENCODING) VALUES (?,?,?,?,?,?,?) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:387) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2146) at org.jpox.store.StoreManager.insert(StoreManager.java:739) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3415) at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3388) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1146) at org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1187) at org.jpox.store.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:409) at org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeObjectField(ParameterSetter.java:132) at org.jpox.state.StateManagerImpl.providedObjectField(StateManagerImpl.java:2627) ... ... ERROR 2: === ERROR 22001: A truncation error was encountered trying to shrink VARCHAR 'cvs update: move away scripts/Database/factorydata/CUSTOMER_' to length 1024. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.types.SQLChar.hasNonBlankChars(Unknown Source) at org.apache.derby.iapi.types.SQLVarchar.normalize(Unknown Source) at org.apache.derby.iapi.types.SQLVarchar.normalize(Unknown Source) at org.apache.derby.iapi.types.DataTypeDescriptor.normalize(Unknown Source) at org.apache.derby.impl.sql.execute.NormalizeResultSet.normalizeRow(Unknown Source) at org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) ... ... ERROR 3: === javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO SCMRESULT (SCMRESULT_ID,SUCCESS,COMMAND_OUTPUT,EXCEPTION,COMMAND_LINE,PROVIDER_MESSAGE,MODEL_ENCODING) VALUES (?,?,?,?,?,?,?) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:387) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2146) at org.jpox.store.StoreManager.insert(StoreManager.java:739) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3415) at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3388) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1146) at org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1187) at org.jpox.store.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:409) at org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeObjectField(ParameterSetter.java:132) at org.jpox.state.StateManagerImpl.providedObjectField(StateManagerImpl.java:2627) at org.apache.maven.continuum.model.project.BuildResult.jdoProvideField(BuildResult.java) at org.apache.maven.continuum.model.project.BuildResult.jdoProvideFields(BuildResult.java) ... ... ERROR 4: === ERROR 22001: A truncation error was encountered trying to shrink VARCHAR 'cvs update: move away
Re: [Continumm 1.0.3] Alot of errors in the continumm log file..
If you change it, can you send us the procedure? we'll add an entry in faqs. Emmanuel Mattias Andersson a écrit : Hi Emmanuel, ok, I'll try to change the column. Thanks for the quick response! Regards, Mattias It's a known problem thazt we'll fix in 1.1. The length of a field (COMMAND_OUTPUT) isn't enought in database, you can change it to a blob with a sql client like squirrel. Emmanuel Mattias Andersson a écrit : Hi, I got some errors today in the continuum log fil that I do know how to solve? The appeared when I pressed the build button for a project. It's a shell project, SCM is CVS and I use continumm 1.0.3. Are these errors known or should I add new isues? And are there any workarounds? (the complete stack trace is not included below to keep the mail smaller. They are available if needed) Regards, Mattias ERROR 1: === cvs update: move away scripts/Database/mssql/Views/dbo.DB_SubRatParamHistory_1.VIW; it is in the way 31802313 [Thread-2] WARN org.apache.maven.continuum.scm.ContinuumScm - Provider message: The cvs command failed. 31802391 [Thread-2] ERROR org.apache.maven.continuum.buildcontroller.BuildController - Error while building project. javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO SCMRESULT (SCMRESULT_ID,SUCCESS,COMMAND_OUTPUT,EXCEPTION,COMMAND_LINE,PROVIDER_MESSAGE,MODEL_ENCODING) VALUES (?,?,?,?,?,?,?) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:387) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2146) at org.jpox.store.StoreManager.insert(StoreManager.java:739) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3415) at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3388) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1146) at org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1187) at org.jpox.store.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:409) at org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeObjectField(ParameterSetter.java:132) at org.jpox.state.StateManagerImpl.providedObjectField(StateManagerImpl.java:2627) ... ... ERROR 2: === ERROR 22001: A truncation error was encountered trying to shrink VARCHAR 'cvs update: move away scripts/Database/factorydata/CUSTOMER_' to length 1024. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.types.SQLChar.hasNonBlankChars(Unknown Source) at org.apache.derby.iapi.types.SQLVarchar.normalize(Unknown Source) at org.apache.derby.iapi.types.SQLVarchar.normalize(Unknown Source) at org.apache.derby.iapi.types.DataTypeDescriptor.normalize(Unknown Source) at org.apache.derby.impl.sql.execute.NormalizeResultSet.normalizeRow(Unknown Source) at org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) ... ... ERROR 3: === javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO SCMRESULT (SCMRESULT_ID,SUCCESS,COMMAND_OUTPUT,EXCEPTION,COMMAND_LINE,PROVIDER_MESSAGE,MODEL_ENCODING) VALUES (?,?,?,?,?,?,?) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:387) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2146) at org.jpox.store.StoreManager.insert(StoreManager.java:739) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3415) at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3388) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1146) at org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1187) at org.jpox.store.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:409) at org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeObjectField(ParameterSetter.java:132) at org.jpox.state.StateManagerImpl.providedObjectField(StateManagerImpl.java:2627) at org.apache.maven.continuum.model.project.BuildResult.jdoProvideField(BuildResult.java) at org.apache.maven.continuum.model.project.BuildResult.jdoProvideFields(BuildResult.java) ... ...
