EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #09870

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

Re: [EP-tech] A changed self - Whachu Know About It?

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

I think looking into manually manipulating object attributes like
{changed} is a little too much like breaking encapsulation.

That should be DataObj.pm's business, and none of my business.

I'm guessing of course.

Rather, I should work with existing methods and see what can be learned,
as regards best practice using them.

A good place to start in learning more,
is simply to experiment with

set_value

and

set_value_raw

methods,

and take a look at the {changed} attribute before and after each.

Anyway, I will park this for now,
and wait until I've the time to conduct such an experiment.

In the meantime, I continue to welcome any two cents,
anyone may wish to contribute on the subject (which just happens to
also be the title of a Bhad Bhabie / Danielle Bregoli track from 2017
- Whachu Know).



Quoting Andrew M <eprints-tech@unitedgames.co.uk>:


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

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

What is your knowledge of working with the object attribute
$self->{changed} for Data Objects?

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.eprints.org%2Fw%2FAPI%3AEPrints%2FDataObj%23.24self-.3E.7Bchanged.7D&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7Ca4713681ad074c80dfa708dcfe4e6d5e%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C638664860137116958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C40000%7C%7C%7C&sdata=v1Fnbv4%2BAh7iN%2BL3Lcwk0FjqY8AZ8lyXsXHv91C2B%2Bw%3D&reserved=0

One of the first things I ever noticed about ChangeName back when I
first begun it, was that I always had to force commit. A normal commit
would never save changes.

Now what's going on there?
Well as far as I understand (and I could very easily misunderstand),
$self->{changed} (where $self is a data object such as an EPrint)
wasn't indicating a change, so without a force, which updates
$self->{data} rather than only field names in the hash reference
$self->{changed}, it wouldn't update anything, because it thought
nothing had changed.
So in the latest revision to ChangeName v2.0.6, I've added two very
simple lines:

(The variable is actually called $fresh_result - and for clarity I'll
just call it $eprint here, since it is normally an eprint object
instance)...

$eprint->queue_all;
$eprint->save_revision;

Queue all will ensure the indexer knows to re-index the eprint after
the changes have been made (the 'all' part of queue_all, again, queues
all data, as opposed to only queuing field names stored under
'changed').
Save revision, will establish a new revision in the history of the
item, so the change is trackable in the history tab, when viewing the
item.

I should have known about these methods earlier, and I didn't.
Of course I shouldn't have had to know about these methods, because
normally, changes are stored in $eprint->{changed}, and when that
attribute is populated with changed field names, the eprint is
automatically flagged for re-indexing, and I'm assuming also for a
history revision (may need to double check that)...without you having
to manually ask for these things...

...but for some reason, changing a name, never affected $eprint->{changed}.
So, the next rabbit hole, one could go down, is exploring how the
{changed} attribute can be manually populated (I've heard it should be
a hash reference with field names as keys, and have not heard what the
key's values should be, so am a little unsure of what the data
structure of {changed} should be).
Or to investigate, why a script like ChangeName might ever need to
manually declare what has changed, and why this isn't done
automatically?

So what is the community's knowledge of working with the object
attribute $self->{changed} for Data Objects like an EPrint...?

As I've discovered, things like queuing for re-indexing and saving
revisions do not appear to happen automatically, if $self->{changed}
is empty or false.
Of course there are methods like $eprint->clear_changed that can be
called from anywhere and ensure {changed} is set to an empty hashref,
XD, lol.

Hence v2.0.6 of ChangeName, in addition to forcing a commit like
previous versions, now also explicitly asks for queuing for
reindexing, and a new history revision, via queue_all and
save_revision methods respectively.

Until I learn more about the best way to set the changed attribute, so
this stuff is done automatically, I'll stick with manually asking for
queue_all and save_revision.

Yours,
Andrew.

P.S. This discussion relates to the following git commit:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feprintsug%2FChangeName%2Fcommit%2F514ffb06191db4a70ea1f41fcf1df8fd622bdd11&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7Ca4713681ad074c80dfa708dcfe4e6d5e%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C638664860137273243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C40000%7C%7C%7C&sdata=3eHoVpUK4udDxCGneUuc5PwrJH%2FuE56z%2BaOG22p8nR4%3D&reserved=0