Hi Jeff,
thanks a lot for reporting back. This sounds like a bug in the migration
scripts. Would you mind filing a Jira ticket with the details you've
discovered? https://jira.duraspace.org/projects/DS
I just looked at a couple of my 5.x instances (one has been upgraded
multiple times from at least 1.5.x, one once from 4.x to 5.x) and the
description column has type "text" for both. So I'm not sure what's
going on for you. I did find another mention of the varchar(48) issue on
dspace-tech back in March sometime, but it looked like that person's
problem eventually was something different. Still, it sounds like the
varchar(48) might perhaps be an intermediate step somewhere?
cheers,
Andrea
On 19/11/15 10:32, Jeffrey Sheldon wrote:
It looks like you have a too long value for something, but don't
actually see too many varchar(48) columns in my 5.x database, so I'm not
sure where this is falling over. Hopefully someone with more experience
with the db migrations will help.
Thanks for the feedback, Andrea. Since the varying number is small, I decided
to grep bitstreamformatregistry in our DSpace 4.3 production SQL and turned up
this:
bitstream_format_id | mimetype | short_description | description |
support_level | internal
---------------------+------------+-------------------+----------------------------------------------------------------------+---------------+----------
11 | image/jpeg | JPEG | Joint Photographic Experts Group/JPEG File Interchange
Format (JFIF) | 1 | f
(1 row)
I'm not sure how that inconsistency persisted with updates (1.8.2 to 3.3 to
4.3) given the active constraint, but it did. What's more interesting is that
the 5.x migration script doesn't automatically catch the difference in table
limits.
Of note, here's a SQL dump from our 4.3 install:
CREATE TABLE bitstreamformatregistry (
bitstream_format_id integer NOT NULL,
mimetype character varying(48),
short_description character varying(128),
description text,
support_level integer,
internal boolean
);
And here's one from 5.3:
CREATE TABLE bitstreamformatregistry (
bitstream_format_id integer NOT NULL,
mimetype character varying(256),
short_description character varying(128),
description text,
support_level integer,
internal boolean
);
That's a sizable difference. Isn't there a way for the migration script to do
a sanity check on the existing table structure before attempting changes or
manipulating populated data? I absolutely know we didn't make this change
ourselves.
-Jeff
--
Dr Andrea Schweer
IRR Technical Specialist, ITS Information Systems
The University of Waikato, Hamilton, New Zealand
+64-7-837 9120
--
You received this message because you are subscribed to the Google Groups "DSpace
Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.
