[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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.
## See http://wiki.eprints.org/w/index.php/Training_Video:Automatic_Fields.
$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
Email: hugo.f.alroe at gmail.com


2015-12-18 11:57 GMT+01:00 Hugo F. Alr?e <hugo.f.alroe at 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
> Email: hugo.f.alroe at gmail.com
>
>
> 2015-12-18 10:45 GMT+01:00 John Salter <J.Salter at 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 at ecs.soton.ac.uk [mailto:
>> eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Yuri
>> Sent: 18 December 2015 09:11
>> To: eprints-tech at 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.
>> >
>> > Email: hugo.f.alroe at gmail.com <mailto:hugo.f.alroe at gmail.com>
>> >
>> >
>> >
>> > *** 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/
>>
>>
>> *** 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/
>>
>> *** 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/
>>
>
>
> *** 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20160115/b22a2c86/attachment.html