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

Reply via email to