Thanks Chathuri, the change in the sql file is working now. While you are fixing the db-scripts pointer issue, it would also be useful to make sure that there are no sql files included in the server binary jars, provided they are not required during the runtime.
Regards, Shahbaz On Tue, May 27, 2014 at 5:27 PM, Chathuri Wimalasena <[email protected]>wrote: > Hi Shabaz, > > You are correct. It does not take the changes made in to > db-scripts/registry-derby.sql. It takes changes > airavata-api/airavata-api-server/src/main/resources/registry-derby.sql. If > you change that script file, build airavata-api-server project and replace > that jar, you should be able to see the changes. I will report a bug and > fix it to use sql scripts inside db-scripts. > > Thanks.. > Chathuri > > > On Tue, May 27, 2014 at 10:31 AM, Shahbaz Memon <[email protected]>wrote: > >> Sure, https://gigamove.rz.rwth-aachen.de/d/id/kFdwJw2oNmYkfR >> >> >> >> >> >> >> On Tue, May 27, 2014 at 4:26 PM, Chathuri Wimalasena < >> [email protected]> wrote: >> >>> Can you share the database script, so I can also try it. >>> >>> >>> On Tue, May 27, 2014 at 10:21 AM, Shahbaz Memon >>> <[email protected]>wrote: >>> >>>> Hi Chathuri, >>>> >>>> My changes are not there. >>>> >>>> Cheers, >>>> >>>> Shahbaz >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, May 27, 2014 at 3:55 PM, Chathuri Wimalasena < >>>> [email protected]> wrote: >>>> >>>>> Hi Shabaz, >>>>> >>>>> Then I believe you change the registry-derby.sql. Yes that's the >>>>> correct way. Can you run the derby client (ij tool) and see whether your >>>>> changes are applied. >>>>> >>>>> >>>>> On Tue, May 27, 2014 at 9:20 AM, Shahbaz Memon >>>>> <[email protected]>wrote: >>>>> >>>>>> For a clean start I remove, >>>>>> apache-airavata-server-0.12-SNAPSHOT/bin/persistent_data. I wonder if it >>>>>> is >>>>>> a right way. >>>>>> >>>>>> Shahbaz >>>>>> >>>>>> On Tue, May 27, 2014 at 3:06 PM, Marlon Pierce <[email protected]>wrote: >>>>>> >>>>>>> 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 >>>>>>> >>>>>>>> >>>>>>> >>>> >>>>>>> ------------------------------------------------------------------------------------------------ >>>>>>> >>>> >>>>>>> ------------------------------------------------------------------------------------------------ >>>>>>> >>>> >>>>>>> >> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
