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