[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[EP-tech] Date Record Created
Hi James,
Hopefully, Symplectic RT2 will make things better.? It uses EPrints CRUD
interface to submit data rather than having its own handler that needs
to run on EPrints and various cron jobs to manage syncing.
I have certainly noted over time that EPrints 3.3.x seems to suffer from
issues with excessive history records being created by third party
applications but these have tended to be null edits for live items
rather than these create then destroy records. That said, I have not
been looking for these, so this may well also have been an issue but
without any serious consequences.
Regards
David Newman
On 24/08/2020 16:21, James Kerwin wrote:
> Hi David,
>
> Thank you for this. I've managed to pin it down to the Symplectic
> Elements "get_records" script. The userid is NULL, but the actor is
>
> "/opt/eprints3/bin/get_records"
>
> Every record with this actor appears to have two revision = 1 entries
> and is created and immediately destroyed. I'm yet to find an EPrint ID
> amongst these that links to a real record. The "/usr/sbin/apache2"
> actor records are behaving as I'd expect.
>
> I wonder why it's behaving in this way. Not to worry, we hopefully
> won't run out of numbers any time soon! It just means the history
> table is gigantic and it's already pretty weighty as it is. I'll look
> into it, but we're hopefully getting RT2 in this lifetime so maybe it
> won't be a problem then.
>
> Thanks,
> James
>
>
>
> On Mon, Aug 24, 2020 at 4:10 PM David R Newman <drn at ecs.soton.ac.uk
> <mailto:drn at ecs.soton.ac.uk>> wrote:
>
> Hi James,
>
> If you are interacting with a third party application then this
> may explain the large number of "empty" eprint IDs.? With just
> human user it is possible you will still get a few of these where
> a user goes to create a record and then never gets round to
> entering any metadata.? They may then at some point go round and
> delete all their "empty" eprint records to tidy things up.?
> However, the automated creation by a third party app seems more
> likely.? You should get the userid and actor for these history
> records to see if you can see a pattern.
>
> Regards
>
> David Newman
>
> On 24/08/2020 16:02, James Kerwin via Eprints-tech wrote:
>> Should I be concerned about the number of "empty" eprint IDs I
>> see in the history table?
>>
>> It appears there are a lot that have two instances of "revision =
>> 1" where the record appears to be briefly created and then
>> immediately destroyed and the relevant ID is skipped over and
>> never used. I am making sure that I only look for "datasetid =
>> eprint".
>>
>> I don't want to get too bogged down with this because it's not
>> the end of the world, but I am tempted to pull on the thread and
>> see what's going on.
>>
>> Thanks,
>> James
>>
>>
>> On Mon, Aug 24, 2020 at 2:41 PM James Kerwin via Eprints-tech
>> <eprints-tech at ecs.soton.ac.uk
>> <mailto:eprints-tech at ecs.soton.ac.uk>> wrote:
>>
>> Ahhhh that's it! Thank you!
>>
>> I'm now slightly embarrassed to say how long I spent
>> searching through the various EPrints tables looking for this.
>>
>> The initial plan is to have a script that looks at how many
>> items are put in the repository and breaks them down by some
>> time period (e.g. month). If it's still wanted I'll make it
>> into a button on the admin side that provides either a
>> spreadsheet/google docs link or maybe even use it as an
>> opportunity to play with graph modules etc.
>>
>> We did look into something similar last year where we get the
>> upload date and proper deposit date (as defined by EPrints)
>> to assess how long items spent in review. This felt a little
>> bit too much like surveilling staff which isn't something I'm
>> on board with so it was quickly dropped. "Do no evil..." and
>> so on.
>>
>> Thanks,
>> James
>>
>> On Mon, Aug 24, 2020 at 2:08 PM John Salter
>> <J.Salter at leeds.ac.uk <mailto:J.Salter at leeds.ac.uk>> wrote:
>>
>> Hi James,
>> The 'history' dataset is your friend here!
>>
>> Are you wanting to do this for a handful of records, or
>> script something?
>>
>> A dataset search along these lines should work:
>> dataset: history
>>
>> datasetid: eprint
>>
>> dataobjid: the eprint id you are interested in
>>
>> action: 'create'
>>
>> The history dataset is searchable via the web interface,
>> but for some older versions or EPrints you might want to
>> add the 'datasetid' to the search form.
>>
>> Let me know if you need more info!
>>
>> Cheers,
>>
>> John
>>
>> *From:*eprints-tech-bounces at ecs.soton.ac.uk
>> <mailto:eprints-tech-bounces at ecs.soton.ac.uk>
>> [mailto:eprints-tech-bounces at ecs.soton.ac.uk
>> <mailto:eprints-tech-bounces at ecs.soton.ac.uk>] *On Behalf
>> Of *James Kerwin via Eprints-tech
>> *Sent:* 24 August 2020 13:43
>> *To:* eprints-tech at ecs.soton.ac.uk
>> <mailto:eprints-tech at ecs.soton.ac.uk>
>> *Subject:* [EP-tech] Date Record Created
>>
>> Afternoon All,
>>
>> In the EPrints database is there data on when a record
>> was created? We have the date an item is deposited which
>> indicates when an item was made live in the repository.
>> The record is created prior to this when a user uploads a
>> file or OA Link through Elements. The record is created
>> in the review buffer.
>>
>> When a record is modified there is a "last mod" date and
>> when it goes into the live archive this is treated as the
>> deposit date.
>>
>> If not I can find a way to make it happen in future. It
>> would be incredibly helpful if I didn't need to do this.
>>
>> Thanks,
>>
>> James
>>
>> *** Options:
>> http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
>> *** Archive: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.eprints.org%2Ftech.php%2F&data=01%7C01%7C%7Cb58635689d40405e916408d84842a142%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=ZdFgXpIOd80e4qdV1DVJVC3Xziv%2FUWKuhBuvkxDL3Qw%3D&reserved=0
>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.eprints.org%2Ftech.php%2F&data=01%7C01%7C%7Cb58635689d40405e916408d84842a142%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=ZdFgXpIOd80e4qdV1DVJVC3Xziv%2FUWKuhBuvkxDL3Qw%3D&reserved=0>
>> *** EPrints community wiki: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.eprints.org%2F&data=01%7C01%7C%7Cb58635689d40405e916408d84842a142%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=n4UvLzFrT2ybnFZWFHfvoDanCykNTaQ7hyXvNb2CRgU%3D&reserved=0
>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.eprints.org%2F&data=01%7C01%7C%7Cb58635689d40405e916408d84842a142%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=n4UvLzFrT2ybnFZWFHfvoDanCykNTaQ7hyXvNb2CRgU%3D&reserved=0>
>>
>>
>> *** Options:http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
>> *** Archive:https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.eprints.org%2Ftech.php%2F&data=01%7C01%7C%7Cb58635689d40405e916408d84842a142%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=ZdFgXpIOd80e4qdV1DVJVC3Xziv%2FUWKuhBuvkxDL3Qw%3D&reserved=0 <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.eprints.org%2Ftech.php%2F&data=01%7C01%7C%7Cb58635689d40405e916408d84842a142%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=ZdFgXpIOd80e4qdV1DVJVC3Xziv%2FUWKuhBuvkxDL3Qw%3D&reserved=0>
>> *** EPrints community wiki:https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.eprints.org%2F&data=01%7C01%7C%7Cb58635689d40405e916408d84842a142%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=n4UvLzFrT2ybnFZWFHfvoDanCykNTaQ7hyXvNb2CRgU%3D&reserved=0 <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.eprints.org%2F&data=01%7C01%7C%7Cb58635689d40405e916408d84842a142%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=n4UvLzFrT2ybnFZWFHfvoDanCykNTaQ7hyXvNb2CRgU%3D&reserved=0>
>
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.avg.com%2Femail-signature%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Demailclient&data=01%7C01%7C%7Cb58635689d40405e916408d84842a142%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=TVfCEljS%2BlMYhxguycf2gwJQc5ODX6Ix%2Bw3NWqfJdjs%3D&reserved=0>
> Virus-free. https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.avg.com%2F&data=01%7C01%7C%7Cb58635689d40405e916408d84842a142%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=n3zIxxX%2FUXtjs4mt2jBwBerqjhehCPPwEtfsaY2UXI4%3D&reserved=0
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.avg.com%2Femail-signature%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Demailclient&data=01%7C01%7C%7Cb58635689d40405e916408d84842a142%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=TVfCEljS%2BlMYhxguycf2gwJQc5ODX6Ix%2Bw3NWqfJdjs%3D&reserved=0>
>
>
> <#m_6353439102992617730_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
--
This email has been checked for viruses by AVG.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avg.com%2F&data=01%7C01%7C%7Cb58635689d40405e916408d84842a142%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=j2WRymsR9%2B39KIRV7lctxgympRFenqbOUvk%2FqwOrmBE%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20200824/4988128d/attachment-0001.html