RT 3.4.x and RT 3.6.x on same backend DB?

Hi RT community,

In order to facilitate the testing, development and migration
from our current RT 3.4.5pre1 to the RT 3.6.4 release, I would
like to run both versions against the same database backend.
The additional attributes that are added to the database by the
etc/upgrade/3.5.1 script do not appear to conflict with anything
in the 3.4.5pre release. Assuming that the session table information
is still the same, it appears that both RT versions can be in use
simultaneously against the same database with no ill effects. Has
anyone tried this? Am I missing any possible problems?

Regards,
Ken

Kenneth Marshall wrote:

Hi RT community,

In order to facilitate the testing, development and migration
from our current RT 3.4.5pre1 to the RT 3.6.4 release, I would
like to run both versions against the same database backend.
The additional attributes that are added to the database by the
etc/upgrade/3.5.1 script do not appear to conflict with anything
in the 3.4.5pre release. Assuming that the session table information
is still the same, it appears that both RT versions can be in use
simultaneously against the same database with no ill effects. Has
anyone tried this? Am I missing any possible problems?

Regards,
Ken

This is a bad idea in general. Any testing environments should be based
against their own databases. The last thing you want to do is corrupt
your production database should something go wrong with the development
environment. I just make a dump file of the live database and import it
into the development environment whenever I need new data to work with

Mathew
Keep up with my goings on at http://theillien.blogspot.com

Kenneth Marshall wrote:

Hi RT community,

In order to facilitate the testing, development and migration
from our current RT 3.4.5pre1 to the RT 3.6.4 release, I would
like to run both versions against the same database backend.
The additional attributes that are added to the database by the
etc/upgrade/3.5.1 script do not appear to conflict with anything
in the 3.4.5pre release. Assuming that the session table information
is still the same, it appears that both RT versions can be in use
simultaneously against the same database with no ill effects. Has
anyone tried this? Am I missing any possible problems?

Regards,
Ken

This is a bad idea in general. Any testing environments should be based
against their own databases. The last thing you want to do is corrupt
your production database should something go wrong with the development
environment. I just make a dump file of the live database and import it
into the development environment whenever I need new data to work with

Mathew
Keep up with my goings on at http://theillien.blogspot.com

Mathew,

I agree with you. The actual initial development and preliminary testing
is against a separate copy of the database. Once all of the basics are
debugged and working properly, we have a training/migration to the new version
hurdle. If we can have training go against the actual production data,
then the migration can be performed in a rolling fashion across the
userbase. Also, it is much easier to get thorough testing if the testers
can use the system in their actual work environment. They can always
fall back to the old production instance if they find a problem. Requiring
users to double-enter ticket updates to test and evaluate the new system
results in missing many of the weird corner cases. These are not giant
database trashing problems, but can take time to isolate and fix.

Regards,
Ken

Hi Ken,

In order to facilitate the testing, development and migration
from our current RT 3.4.5pre1 to the RT 3.6.4 release, I would
like to run both versions against the same database backend.
The additional attributes that are added to the database by the
etc/upgrade/3.5.1 script do not appear to conflict with anything
in the 3.4.5pre release. Assuming that the session table information
is still the same, it appears that both RT versions can be in use
simultaneously against the same database with no ill effects. Has
anyone tried this? Am I missing any possible problems?

This has been discussed before I think. The changes between 3.4 and
3.6 are data inserts within the existing schema so there is no reason
(other than the one previously given) to prevent you using different
versions against the same database. I’m currently working on this
myself.

Regards, Ian.