Hi all,
Yeah, I probably over/understated the state of what support exists, it’s more a gap in our ability (including financial….) to access it. I’m absolutely delighted at all the responses here, thank you all!
In particular:
· Eric, thanks, that script to calculate the hash will be perfect to fill in the gaps in my Plan A!
· Jon, that tool looks great and would be perfect – and I’ve got it working to download metadata – however it’s not downloading any files at all. I’m not sure if I’ve missed a tickybox or other setting or (probably more likely) if we’ve just uploaded all our files in a way that hits one of the documented limitations in the export function.
If nothing else, though, I can use it to confirm the version number for all our files, instead of just assuming they’re all version 1, which will help with Plan A too.
Deborah
From: Code for Libraries <[log in to unmask]> On Behalf Of Jon Fackrell
Sent: Tuesday, 29 September 2020 4:16 AM
To: [log in to unmask]
Subject: Re: [CODE4LIB] Equella database structure
Hi there,
I would agree with Eric that Equella is not really abandonware. We are
using it for course content delivery at BYU-Idaho and work with Unicon who
provide our hosting and support.
Eric, I was surprised as well to see an openEquella question on this
listserv.
Deborah, I would recommend the openEquella Bulk Importer (EBI
https://github.com/openequella/openEQUELLA-ebi)<https://github.com/openequella/openEQUELLA-ebi)> tool. Contrary to what the
name suggests, it actually does have an export option in the Options tab.
This will allow you to export all of the metadata to a csv and download all
of the files.
Jon Fackrell
On Mon, Sep 28, 2020 at 8:51 AM Eric Phetteplace <[log in to unmask]<mailto:[log in to unmask]>> wrote:
> Hi Deborah,
>
> I manage an openEQUELLA instance. It's not abandonware, it's under the
> Apereo Foundation now: https://www.apereo.org/projects/openequella<https://www.apereo.org/projects/openequella>
>
> You could probably pay Unicon or Edalex for one-time support such as help
> with a migration. We have an annual contract for support with Unicon and
> they're helpful, they have people who have worked on EQUELLA for a long
> time.
>
> I have a version of the database schema somewhere but it sounds like that's
> not really the problem, you want to know how to convert an item's UUID and
> version into the path on the server where its attachments are stored. The
> folder is a hash of the UUID calculated in a certain way, here's the script
> I use to determine it:
> https://gist.github.com/phette23/9279de4260ff681cbdfc12e10275e2d3<https://gist.github.com/phette23/9279de4260ff681cbdfc12e10275e2d3>
>
> So the path to the attachments directory can be constructed like: { data
> directory }/Institutions/{ institution name }/Attachments/{ hash of item
> UUID }/{ item UUID }/{ item version }
>
> This assumes you're not using advanced storage, which adds an additional
> directory in there with the collection's UUID in between "Attachments" and
> the UUID hash.
>
> I hope that's helpful. I honestly don't understand much about the hash
> itself, I only know that this script works to find it. I'm happy to answer
> other openEQUELLA questions. I'm actually surprised to hear someone else
> out there uses it, I think this is the first time it's come up on the
> listserv.
>
> Best,
> Eric
>
>
> On Mon, Sep 28, 2020 at 2:40 AM Joe Hourclé <[log in to unmask]<mailto:[log in to unmask]>> wrote:
>
> > I can’t say I’m familiar with the software, but it sounds to me like
> > they’re obfuscating the path to slow people who might try scraping the
> > archive
> >
> > It’s likely that the number is in the database, but it might also be a
> > value that’s computed based on other information in the record
> >
> > But before you go and dig through the code, you might have another
> > solution .... just looking at the file system. If it’s mounted on a
> > Unix-like system you could get a directory report with either ‘du’ (disk
> > usage), a recursive directory listing (‘ls -r’ or ‘ls -R’ depending on
> the
> > implementation), or ‘find’ for normal files (‘find directory_to_search
> > -type f’)
> >
> > Of course, then you have to either move the files out of the random
> > directory (or symlink them), or take that report, extract the info and
> > merge it with your database dump
> >
> > If I were to try to do it mostly looking from the database side f things,
> > I would grab a few records (‘select * from TABLE limit 5’) And then look
> > for fields with numbers in them that look out of place
> >
> > -Joe
> >
> > Ps. Note to self: Typing Unix commands on a fake keyboard with
> > autocorrect really sucks
> >
> >
> > Sent from a mobile device with a crappy on screen keyboard and obnoxious
> > "autocorrect"
> >
> > > On Sep 27, 2020, at 5:43 PM, Fitchett, Deborah <
> > [log in to unmask]<mailto:[log in to unmask]>> wrote:
> > >
> > > Kia ora,
> > >
> > > On the off-chance anyone's familiar with (Open)Equella (it's
> essentially
> > abandonware so the ex-vendor's no help, I get error messages when looking
> > for the community Google Group, and the only documentation I can find
> > helpfully has a page linked from the text "Why does the openEQUELLA
> schema
> > make no sense?"<
> > https://openequella.github.io/tutorials/reporting/SchemaDesign.html<https://openequella.github.io/tutorials/reporting/SchemaDesign.html>>
> > which is at least reassuring that it's not just me!)
> > >
> > > I need to migrate out of Equella into another system. I've created a
> > report in the SQL database to extract the metadata for the items I need -
> > but I also need their files, so I want the filepath on the server.
> > >
> > > The files are named with the attachment name (which I have), inside a
> > directory named with the item id (which I have), inside another directory
> > named with a pseudo-random number - ranging from about 0 to about 160,
> from
> > memory. I'm hoping this number is stored somewhere in the SQL database -
> > but I haven't been able to find *where*. Help?
> > >
> > > (I do have other directions I could approach this from but nothing's
> > obviously *easy* and I'm not sure of the capacity of the people who
> > actually have server access, so, just, argh. Migrations.)
> > >
> > > Deborah
> > >
> > > ________________________________
> > >
> > > "The contents of this e-mail (including any attachments) may be
> > confidential and/or subject to copyright. Any unauthorised use,
> > distribution, or copying of the contents is expressly prohibited. If you
> > have received this e-mail in error, please advise the sender by return
> > e-mail or telephone and then delete this e-mail together with all
> > attachments from your system."
> >
>
________________________________
"The contents of this e-mail (including any attachments) may be confidential and/or subject to copyright. Any unauthorised use, distribution, or copying of the contents is expressly prohibited. If you have received this e-mail in error, please advise the sender by return e-mail or telephone and then delete this e-mail together with all attachments from your system."
