EPrints Technical Mailing List Archive

Message: #09199

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] get_all_documents from eprint trigger on commit

CAUTION: This e-mail originated outside the University of Southampton.
Hi John,

Thanks for the reply.

If it's ok with you, I'll email you directly with my script in its current testing state. No pressure if you're busy with your own work. I just can't get it to work, even with "fresh" eyes.

Wrt to using a commit in a commit trigger, is there a good way to update a value using a commit trigger? Part of this workflow involves applying the license for some items and ideally moving some others to the work area to be dealt with by another process downstream. The possibility of a loop did occur to me, but I quietly crossed my fingers and hoped for the best.

I THINK I possibly stumbled into a bad loop last night while using Dumper to print some very large item. The deposit hung in Elements forever. My Apache log swelled to 10GB and I couldn't stop it. In the end I deleted the log file and was finally able to stop and start Apache. Then I thought I'd lost the work I've been doing (I hadn't) and called it a night.

Thanks,
James

On Tue, Feb 7, 2023 at 10:50 AM John Salter <J.Salter@leeds.ac.uk> wrote:

Hi James,
I think this should work OK. Happy to take a look at the full code in case there's something that stands out.

I would be cautious though - in your example, you call the AFTER_COMMIT trigger, and in there update a sub-object (the document) can then call the EPrint->commit - which will lead to the eprint BEFORE_COMMIT and AFTER_COMMIT triggers being fired - ending in a bit of a loop. (I don't think this is your problem, but worth mentioning).

 

Cheers,

John

 

From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of James Kerwin via Eprints-tech
Sent: 07 February 2023 09:29
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] get_all_documents from eprint trigger on commit

 

CAUTION: This e-mail originated outside the University of Southampton.

Hi All,

 

I'm doing some work around our rights retention policy. It involves checking if something was deposited before or after the date it comes into effect. Quite a big piece of work for me and I'm happy to share code/workflow etc.

 

I have a script that is kicked off by an eprint trigger on commit. Is it possible for me to use "get_alldocuments" from this? I was able to do this in a /bin script using:

 

my $eprintid = 3000633;

 

my $eprint = $ds->dataobj($eprintid);

my @documents_list  = $eprint->get_all_documents;

 

foreach my $document (@documents_list) {

$document->set_value('license','cc_by_4');

 

$document->commit();

}

 

Carrying this over into a trigger which starts with:

 

$c->add_dataset_trigger( 'eprint', EP_TRIGGER_AFTER_COMMIT, sub
{
     my( %args ) = @_;

     my( $repo, $eprint, $changes ) = @args{qw( repository dataobj changed )};

 

I was at it until 3am trying all sorts of different things. Using Data:Dumper to print the content of @documents to the error log, along with some other checkpoints, I can see that the section of code is entered into, but it just moves past @documents without printing anything and gets to the print statement immediately after. The only reasonable conclusion being that it isn't finding any documents. It seems reasonable that as this is an "eprint" trigger I can't access documents, but I know that in a slightly different script I can grab all the documents with only an EPrint ID, which I have here along with the $repo.

 

Can anybody please tell me if this approach is possible and maybe what I'm doing wrong? (Happy to share the entire script and everything else related to this project whether advice is forthcoming or not). If it isn't possible, my solution would be to push all of the IDs into a file, then have a script that slurps them up and does the "get_all_documents" on them, but that would be a far worse solution in terms of workflow.

 

Thanks,

James