Import from 2.0.13 to 3.20 is not correct

Hello All,

Currently I’m trying out the new RT 3.2.0 release and I’m importing my
data from a RT 2.13 install which is using Oracle as a backend into the
new install which is also using Oracle as backend, Oracle9i to be
precise.

I modified the RT2 instance to work with Oracle and haven’t had any
problems with it that includes attachments getting into the database and
getting them out. I modified the schema to use CBLOB’s and modified
SearchBuilders Handle/Oracle.pm to use unsafe binary blobs. This results
into base64 encoded attachments in the database which is correct.
When I export the RT2 instance using rt2-rt3 1.23 I get dumps in which
it says Content-Transfer-Encoding: base64 followed by the binary data,
in my sample case a zip file. Sofar this looks correct and according to
rt2-dumpfile this is also expected behaviour.
The problem is in the import into the RT3 instance. Here SearchBuilder
also assumes unsafe binary blobs for Oracle and I would have expected to
see base64 encoded data in the attachments table in the Content column
but instead I find binary data and I’m not sure what has happened to it.
The zip header looks OK but strangely enough a couple of bytes have
change among them a B9 to BF, checked through export function of Oracle.
It looks like the dumpfile-tp-rt3.0 is doing something wrong or the code
in RT3.2.0 is not doing the right thing. If I look at that ticket from
the WebUI then I see that its size is just 29bytes instead of ~2Kb and
clicking on it and saving it shows me really some garbage which isn’t
recognisable as a zip file at all.

Anyone who can comment on this? Jesse?

Thanks in advance,

Joop

Joop van de Wege JoopvandeWege@mococo.nl

Just to comment on my own post. I have inserted a test attachment into
the RT3.2.0 instance using the WebUI and looked at the database and it
is there properly base64 encoded.

It looks like dumpfile-to-rt3.0 uses a shortcut to get
tickets/attachments into the database and doesn’t do proper encoding of
the attachment.

Hope this helps to find the problem.

Just for completeness:
RT 3.2.0
make testdeps is OK
Perl 5.8.4
Oracle9i
Apache/1.3.29 (Unix) PHP/4.3.4 mod_fastcgi/2.2.12 mod_ssl/2.8.16 OpenSSL/0.9.7c

Joop van de Wege JoopvandeWege@mococo.nl

Anyone who can comment on this? Jesse?

The tools were designed to work with our supported, shipped database
configs. I’m not sure what a custom Oracle port of RT2 might be doing
that could break things.
Jesse

Anyone who can comment on this? Jesse?

The tools were designed to work with our supported, shipped database
configs. I’m not sure what a custom Oracle port of RT2 might be doing
that could break things.
Jesse
As I wrote to the list it is not the Oracle port of RT2 that is breaking
things but the import into RT3. See also rt-users list for someone else
who is having problems using a standard supported configuration.
He actually identified the place in dumpfile-to-rt3.0 where things go
awry.

Joop

Joop van de Wege JoopvandeWege@mococo.nl

Jesse

As I wrote to the list it is not the Oracle port of RT2 that is breaking
things but the import into RT3. See also rt-users list for someone else
who is having problems using a standard supported configuration.
He actually identified the place in dumpfile-to-rt3.0 where things go
awry.

The dumpfile-to-3.0 expects attachments and content to already be
well-formed for your chosen database. For mysql->mysql or Pg->Pg, this
should already be true. I can’t say whether a third-party port of RT2 to
oracle will have things set up correctly. Of course, patches are gladly
accepted :wink:

Jesse