Which database (derby or mysql) are you using? Did you start from a clean DB after changing the .sql?
Marlon On 5/27/14 9:03 AM, Shahbaz Memon wrote: > As I mentioned in one of my previous emails that, there is no effect of > changing the > "apache-airavata-server-0.12-SNAPSHOT/bin/database_scripts/registry-*.sql" > files. > > Cheers, > > Shahbaz > > > On Mon, May 26, 2014 at 6:54 PM, Raminder Singh > <[email protected]>wrote: > >> Files used at the runtime are at location 1. Sql in the jars are used for >> unit testing and other component development. Ideally all these files are >> in sync. Changing files in distribution can keep you moving. >> >> Thanks >> Raminder >> >> On May 26, 2014, at 12:20 PM, Shahbaz Memon <[email protected]> wrote: >> >> Thanks Marlon and Chathuri for the clarification. But I need a bit more >> help to understand which sql files are suppose to be used. >> >> After building the server's binary distribution I see registry-*.sql files >> in three locations, >> >> 1) apache-airavata-server-0.12-SNAPSHOT/bin/database_scripts/registry-*.sql >> 2) >> apache-airavata-server-0.12-SNAPSHOT/lib/airavata-jpa-registry-0.12-SNAPSHOT.jar >> (contained) >> 3) >> apache-airavata-server-0.12-SNAPSHOT/lib/airavata-api-server-0.12-SNAPSHOT.jar >> (contained) >> >> Is it the 3 location which is being considered? If so, are 1 and 2s' sql >> files being used by any other component during server runtime? >> >> Cheers, >> >> Shahbaz >> >> >> On Mon, May 26, 2014 at 4:07 PM, Chathuri Wimalasena <[email protected] >>> wrote: >>> Hi Shabaz, >>> >>> Registry is initiated when airavata server starts. That's why sql files >>> are at airavata-api/airavata-api-server/src/main/resources. If you want >>> to change the database, you want to edit those script files. If it is a >>> change in table names or columns, you need to change associate openJPA >>> model classes too. >>> >>> Thanks.. >>> Chathuri >>> >>> >>> On Mon, May 26, 2014 at 8:59 AM, Marlon Pierce <[email protected]> wrote: >>> >>>> The versions in >>>> airavata/modules/registry/airavata-jpa-registry/src/main/resources/ >>>> should be the ones that are used to set up the databases. Can you check >>>> the DB itself to see if the settings were changed? >>>> >>>> Someone else will have to explain why the .sql files are also in the API >>>> server directory >>>> (./airavata-api/airavata-api-server/src/main/resources/) but I suspect >>>> it is related to our dependency on OpenJPA calls in the current version >>>> of the Registry CPI. >>>> >>>> Marlon >>>> >>>> On 5/26/14 8:28 AM, Shahbaz Memon wrote: >>>>> Now I have tried to increase the "varchar" capacity of the job_id >>>> attribute >>>>> to 1000, but still not able to avoid the truncation error. >>>>> >>>>> Here is the trace, >>>>> >>>>> http://www.heypasteit.com/clip/1E0D >>>>> >>>>> By the way when I dissect the server distribution I see that there are >>>>> registry-derby.sql and registry-mysql.sql files in the >>>>> <apache-airavata-server-path>/bin/database-scripts/, and two files >>>> with the >>>>> same name can also be found inside the >>>>> airavata-jpa-registry-0.12-SNAPSHOT.jar. I am not sure which one is >>>> loaded >>>>> during the run time, although I have changed both, but still see no >>>> impact >>>>> on the mysterious database creation phase that is exporting >>>> <table>.job_id >>>>> attribute with 255 chars. >>>>> >>>>> Thanks, >>>>> >>>>> Shahbaz >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, May 26, 2014 at 9:26 AM, Shahbaz Memon <[email protected] >>>>> wrote: >>>>> >>>>>> Hi Marlon, >>>>>> >>>>>> Thanks for your reply. In unicore, jobs possess a complex >>>> ws-addressing >>>>>> endpoint reference type structure which will be for sure exceeding the >>>>>> limit of 255 chars. >>>>>> >>>>>>> If you changed the definition of JOB_DETAIL here to use more >>>> characters, >>>>>> would this solve your problem? >>>>>> >>>>>> I was not able to apply the changes. I will try it this week and see >>>> how >>>>>> it works. >>>>>> >>>>>> Thanks and best regards, >>>>>> >>>>>> Shahbaz >>>>>> >>>>>> >>>>>> >>>>>> On Fri, May 23, 2014 at 4:40 PM, Marlon Pierce <[email protected]> >>>> wrote: >>>>>>> Hi Shahbaz, did my workaround suggestion work for you? >>>> Fundamentally, >>>>>>> though, we need to make the size limit on the jobId explicit to the >>>>>>> plugin developer, or else come up with a solution that doesn't >>>> require >>>>>>> modifying the field size in the DB schema, since we can't assume in >>>> all >>>>>>> cases that plugin developers have access to the registry config file. >>>>>>> >>>>>>> >>>>>>> Marlon >>>>>>> >>>>>>> On 5/16/14 10:22 AM, Shahbaz Memon wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> At the BES provider side when I am try to save submitted job details >>>>>>> through GFacUtils.saveJobStatus(jobExecutionContext,details, >>>>>>> JobState.SUBMITTED); >>>>>>>> The provider throws an exception, the whole trace can be accessed >>>> under, >>>>>>>> http://www.heypasteit.com/clip/1DFF >>>>>>>> >>>>>>>> May be the database model is limiting the provider instance to >>>> insert >>>>>>> complete job reference. >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Shahbaz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> ------------------------------------------------------------------------------------------------ >>>> ------------------------------------------------------------------------------------------------ >>>>>>>> Forschungszentrum Juelich GmbH >>>>>>>> 52425 Juelich >>>>>>>> Sitz der Gesellschaft: Juelich >>>>>>>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 >>>>>>>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher >>>>>>>> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), >>>>>>>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, >>>>>>>> Prof. Dr. Sebastian M. Schmidt >>>>>>>> >>>> ------------------------------------------------------------------------------------------------ >>>> ------------------------------------------------------------------------------------------------ >>>> >>
