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 >>> >>>> >>> >>> >>> ------------------------------------------------------------------------------------------------ >>> >>> >>> ------------------------------------------------------------------------------------------------ >>> >>>> >>> >>> >>> >>> >> > >
