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