rt2-to-rt3 is now at version 1.13 and still under development directory.
Is there a time line as to when it will be ready for production?
And, are there any ‘speed ups’ planned? Right now I am testing
rt2-to-rt3 on a 150M database (postgresql-7.2.3-5.73) with about
4800 tickets (redhat 7.3 , 1.4GHz athlon, 512 MB ram):
the dump is at ticket 718 currently, and it been about 40 minutes.
Is this to be expected? I am a bit concerned as the current
production rt has 81000+ tickets (and I don’t even want to think
about the size in bytes).
And,
Has any consider integrating ‘cpan2rpm’ with 'rt-test-dependencies’
script? So far I tried
for name in `perl rt-test-dependencies --with-modperl1
Which has serious limititations, like for instance if a dependency has it
own dependencies, then the rpm build will fail. But, the good thing is
about 20 rpms were built (which is probably due most depencies being met).
rt2-to-rt3 is now at version 1.13 and still under development directory.
Is there a time line as to when it will be ready for production?
It pretty much is.
And, are there any ‘speed ups’ planned? Right now I am testing
rt2-to-rt3 on a 150M database (postgresql-7.2.3-5.73) with about
4800 tickets (redhat 7.3 , 1.4GHz athlon, 512 MB ram):
the dump is at ticket 718 currently, and it been about 40 minutes.
Is this to be expected? I am a bit concerned as the current
production rt has 81000+ tickets (and I don’t even want to think
about the size in bytes).
That’s why the importer has an incremental mode. Read the README.
[Please keep list discussion on the list. Thanks.]
mixo wrote:
Well ‘dumpfile-to-rt-3.0’ requires rt3 to be installed locally, and
‘rt-2.0-to-dumpfile’ requires rt2.
Correct.
Correct if I am wrong, but this means that one cannot export rt2 data
from one machine to another
You’re wrong. Run rt-2.0-to-dumpfile on the machine with
RT2 installed, copy the data over to the RT3 machine, and run
dumpfile-to-rt-3.0 there.
I stand corrected.
Total time taken for the export: 4 hours, 13 minutes
I’ve seen worse.
Total time for import: 7 hours, 10 minutes
That’s why the importer has an incremental mode. Read the README.
Well, I just got the production dump, and its 24 Gigs …
You really want to make yourself familar with that incremental
exporter, then.
I have seen the incremental mode, which leads me to my next question:
can the
initial data export (dump) be started in incremental mode? I am
considering only
doing a dump from say the begining on this year, and using that instead.
The plan
would be at the end of a certain period, like a year, do a dump of the
db (using the
db’s utils) and store it somwhere, after then do the incremental dump of
the past
month (just an example) and do a fresh rt install with data for the past
month.
So in the end there would be an archive of rt for each in case there was
ever a
need to refer to old data. Just a thought…
P.S Another thought :
Emails from rt-users and rt-devel lists don’t have a ‘reply-to’ field, which
means some of us will accindentally reply to inviduals and not the lists as
the “reply” button in some email clients pick up the “from” field if
the “reply-to” one doesnt exist. I 'm one of those poeple who clicks on
“reply”.
can the
initial data export (dump) be started in incremental mode? I am
considering only
doing a dump from say the begining on this year, and using that instead.
Nope, you’ll miss out on a lot of metadata that way.
The plan
would be at the end of a certain period, like a year, do a dump of the
db (using the
db’s utils) and store it somwhere, after then do the incremental dump of
the past
month (just an example) and do a fresh rt install with data for the past
month.
How much data are you accumulating in a year?
Emails from rt-users and rt-devel lists don’t have a ‘reply-to’ field, which
means some of us will accindentally reply to inviduals and not the lists as
the “reply” button in some email clients pick up the “from” field if
the “reply-to” one doesnt exist. I 'm one of those poeple who clicks on
“reply”.
can the
initial data export (dump) be started in incremental mode? I am
considering only
doing a dump from say the begining on this year, and using that instead.
Nope, you’ll miss out on a lot of metadata that way.
Then adding an option to collect only metadata to the export script
would be useful. Would it
break anything though?
The plan
would be at the end of a certain period, like a year, do a dump of the
db (using the
db’s utils) and store it somwhere, after then do the incremental dump of
the past
month (just an example) and do a fresh rt install with data for the past
month.
How much data are you accumulating in a year?
The 81000+ tickets were created between 12 June 2001 and 12 May 2003,
which is roughly
40 000 tickets per year. This is just an estimate.
Emails from rt-users and rt-devel lists don’t have a ‘reply-to’ field, which
means some of us will accindentally reply to inviduals and not the lists as
the “reply” button in some email clients pick up the “from” field if
the “reply-to” one doesnt exist. I 'm one of those poeple who clicks on
“reply”.
Run rt-2.0-to-dumpfile on the machine with