The migration guide [1] that you referred to does provide a rough
upgrade script. It looks like it tries to maintain information because
it's not just a simple drop all tables, create all new tables script.
[1]
http://quartz-scheduler.org/documentation/quartz-2.1.x/migration-guide
On 5/2/2013 9:10 AM, Thomas Segismont wrote:
> Hi Mazz,
>
> Yes they changed tables structure in recent versions of Quartz. We
> could keep the old tables and write some code to migrate existing jobs
> and triggers. I'll search the Quartz forums to check if someone
> already went down that path.
>
> I'll update the BZ with my findings.
>
> Thomas
>
> Le 30/04/2013 19:21, John Mazzitelli a écrit :
>> IIRC, upgrading to the latest quartz would require some of our _QRTZ
>> tables to be upgraded (I think one or more tables in quartz require
>> schema updates).
>>
>> Just keep that in mind - it will require upgrading testing - and
>> since we use quartz for lots of jobs (either our internal async jobs
>> or jobs to invoke scheduled operations that users define) we have to
>> make sure those jobs/scheduled operations are not broken during the
>> upgrade.
>>
>> In fact, we'll need to test this EVEN IF there are no schema updates
>> for quartz - we need to make sure the jobs in the _QRTZ tables are
>> forward compatible to be executable in the new quartz.
>>
>> ----- Original Message -----
>>> Hi everyone,
>>>
>>> Recently I filed this BZ for Quartz upgrade:
>>>
https://bugzilla.redhat.com/show_bug.cgi?id=957691
>>>
>>> Upgrading Quartz to latest version would give us many bug fixes that
>>> will save our and users/customers time in the future.
>>>
>>> Worth reading:
>>>
http://quartz-scheduler.org/documentation/quartz-2.x/new-in-quartz-2
>>>
http://quartz-scheduler.org/documentation/quartz-2.1.x/new-in-quartz-2_1
>>>
>>>
http://quartz-scheduler.org/documentation/quartz-2.1.x/migration-guide
>>>
>>> Upgrading will make us rework pieces of code calling Quartz APIs and
>>> update Quartz tables in the database.
>>>
>>> This could be made in master branch after RHQ 4.7 release and would
>>> give
>>> us the time of a full release cycle to test/get feedback.
>>>
>>> What do you think?
>>>
>>> Thanks and regards,
>>> Thomas
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel(a)lists.fedorahosted.org
>>>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel(a)lists.fedorahosted.org
>>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel