EPrints Technical Mailing List Archive

Message: #05332

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

[EP-tech] Re: Editoring speed problem and Review queue option

Hi John 
Thank you for your help. The video was immensely helpful. We implemented the new automatic field by adding a new configuration file (se file below) and  added the field conf_subm ("Conference submissions, Yes, No") to the editor rights restrictions. This was a bit difficult to find, but it is done in the search.pl file, in "editor_limit_fields", where I added the line:
"conf_subm", # HFA 6jan2016: Added to allow for selecting the automatic conference submission field 
I added phrases by way of "Edit page phrases".

It works fine. Speed gain on a review buffer of 412 eprints: before (15 restrictions) = 256 seconds to see a buffer of 100, after (1 restriction) = 8 seconds to see a buffer of 100. That is, about 30 times faster.

Best regards,
Hugo


----eprint_type_conf_subm.pl----
## HFA 2016jan06: This automatic field function is meant to solve the problem with very slow speed when editors work in their buffer, 
## because most national editors have 15 eprint types (all but the conference submissions) in their editorial rights restrictions to 
## avoid conference submissions being moved into the archive prematurely by the national editors. 
## Any editorial-scope options that are 'set' or 'namedset' fields create some big SQL statements when used together 
## (lots of ORs over lots of tables). See Eprints Tech list mail 18dec2015 on "Editoring speed problem and Review queue option".
## An automatic field that stores a value 'subm' or 'not_subm' will give a much more efficient 
## (and hopefully quick-enough) way to restrict the review queue for conference submissions.
## This will create a field (called 'conf_subm')to use for groupings of editorial rights for eprint type 'submission', 
## one group for conference submissions and another for alle the other eprint types.
$c->add_dataset_field('eprint',
{
name => 'conf_subm',
type => 'set',
options => [
'subm',
'not_subm',
]
}
);

$c->{set_eprint_automatic_fields_eprint_type_conf_subm} = $c->{set_eprint_automatic_fields};
$c->{set_eprint_automatic_fields} = sub
{
my( $eprint ) = @_;
my $repo = $eprint->repository;
$repo->call('set_eprint_automatic_fields_eprint_type_conf_subm', $eprint);
## Set value according to eprint type submission or not
my $type = $eprint->get_value( "type" );

if( $type eq "submission")
{
$eprint->set_value( "conf_subm", "subm" );
}
else
{
$eprint->set_value( "conf_subm", "not_subm" );
};
}
----end of file----

Hugo F. Alrøe


2015-12-18 11:57 GMT+01:00 Hugo F. Alrøe <hugo.f.alroe@gmail.com>:
Thank you, John,
Yes, that was our thought as well, that it was the database queries that multiplied.
Thank you for the idea on using automatic fields to simplify the proces. As I understand you, this will only influence on how the editorial rights are handled, and not require changes to the eprints types and how the user sees this. It sounds like a doable approach to the problem, and I will look into it. 
We would probably still like to use the Reviewed Queue package to help the conference reviewing process, but in a way where we won't rely on it as an essential element in submission process.  
Cheers,
Hugo

Hugo F. Alrøe


2015-12-18 10:45 GMT+01:00 John Salter <J.Salter@leeds.ac.uk>:
Hi,
I think that any editorial-scope options that are 'set' or 'namedset' fields create some big SQL statements when used together (lots of ORs over lots of tables).

It sounds like you need one group for (not conference) and another for (conference).

My approach to this would be to create a field to use for groupings of editorial rights (http://wiki.eprints.org/w/index.php/Training_Video:Automatic_Fields).
If you have an automatic field that stores a value 'conf' or 'not_conf' - you then have a much more efficient (and hopefully quick-enough) way to restrict the review queue.

I can't comment on the 'Reviewed' package in the Bazaar - I haven't used it.

Cheers,
John

-----Original Message-----
From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of Yuri
Sent: 18 December 2015 09:11
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] Re: Editoring speed problem and Review queue option

Isn't better to fix the slowness? i wouldn't depend, on big projects, on
plugins found on Bazaar if I'm not sure they're well mantained.

Il 18/12/2015 09:39, Hugo F. Alrøe ha scritto:
> Hi
>
> We have experienced speed problems when editoring on our archive
> Organic Eprints (www.orgprints.org <http://www.orgprints.org>). We
> have +30 editors with responsibilities for different countries and
> projects, and some of them, but only some, experience that the system
> is very slow when they are working with the review buffer. Search etc.
> is not affected.
>
> I finally found out that the number of editorial rights restrictions
> affect the speed of showing the review buffer substantially. We have
> some 16 eprint types (yes, I know, too many, but the archive has many
> different kinds of eprints), and one of these (conference submissions)
> has to be handled by different editors. This means most of our
> national editors have 15 eprint types (all but the conference
> submissions) in their editorial rights restrictions, to avoid
> conference submissions being moved into the archive prematurely by the
> national editors. Some editors have a number of countries and projects
> as well in their editorial rights restrictions, which means that
> showing the buffer can be veeery slow (like, go get a cup of coffee,
> start on something else, and forget about it).
>
> To solve this problem, I think about handling the conference
> submissions differently. In the ePrints Bazaar I found the Reviewed
> queue package, which offers a functionality that potentially can meet
> this purpose by establishing an additional review buffer.
>
> For this to work however, eprints of type conference submissions
> should go automatically into this additional buffer. Is this possible?
> And if so, how?
>
> And preferably it should be possible to restrict most editors from
> seeing this additional buffer. We have editors with different powers
> already (some being able to modify the subject trees to e.g. add new
> research affiliations). But I am not sure whether the additional
> buffer established by Reviewed queue can be allocated to a specific
> editor type. Is this possible?
>
> Can anybody help on these questions?
>
> Best regards
> Hugo Alroe
> Initiator (in 2002) of Organic Eprints and presently temporary archive
> administrator.
>


*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/