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

[EP-tech] Virtual Field derived by SQL query or code and available for searching.



Hi Brian

	Virtual fields have no value stored in the database.  Therefore, you can't search on them.  The virtualwithvalue field was created to allow virtual fields to write back to the non-virtual fields they are based on, which can be useful in some situations.  From your code below, I believe that calling set_value will cause a stack overflow, as $eprint->set_value('fulltext', 'TRUE') will make a call to $eprint->set_value('fulltext', 'TRUE') until the computer runs out of stack space.

	In a default eprints repository, there's already a field for this -- full_text_status.  Try adding that to your search configuration and see what happens :)  It's managed as an automatic field, rather than a virtual one, which sounds like what you need.  There's a training video for that, too: https://wiki.eprints.org/w/Training_Video:Automatic_Fields

	See:

	https://github.com/eprints/eprints/blob/392474eec1b8125a66ed2d3e12b02aeb67dc07c4/lib/defaultcfg/cfg.d/eprint_fields_automatic.pl#L30

	...as an aside, I've always thought that the behaviour of this field is wrong.  It should be a multiple field, so that we can distinguish between items that have only restricted documents, items that have only public documents and items that have both.

--
Adam


On 13 Apr 2017, at 18:10, Brian D. Gregg <bdgregg at pitt.edu> wrote:

> All,
> 
> I've delved into testing Adam Fields excellent video on Virtual fields (http://www.youtube.com/watch?v=GjeWcewJA5o) which works perfectly for creating a derived "display" only value visible within the abstract page, however when adding the newly created Virtualwithvalue type field into the advanced search form and searching against it returns zero results (at least on our system here).  I expect that there is some tweak needed or some additional voodoo needed to get that to work correctly which I think I've only seen the tip of the iceberg at this point.
> 
> What I've been asked to investigate is adding a field to the advanced search that would indicate if the Eprint has full text or not (to allow for searching of only full text items) as we have both metadata only and full text items in our IR and the wish is to only search items that contain full text.
> 
> I've been able to create a virtual field as follows:
> 
> In my zz_local_fields.pl file I've created the get_value and set_value properties as follows base upon Adam's video and some code:
>     name => 'fulltext',
>     type => 'virtualwithvalue',
>     virtual => 1,
>     get_value => sub
>     {
>         my ($eprint) = @_;
>         my $val = '';
>         if ( $eprint->get_all_documents == 0 )
>         {
>            $val = "FALSE";
>            return $val;
>         } else {
>            $val = "TRUE";
>            return $val;
>         }
>     },
>     set_value => sub
>     {
>         my ($eprint, $value) = @_;
>         if ( $eprint->get_all_documents == 0 )
>         {
>             $eprint->set_value('fulltext',"FALSE");
>         } else {
>             $eprint->set_value('fulltext',"TRUE");
>         }
>     }
> 
> This "derived" field works perfectly within the abstract view.  The definition of an Eprint containing full text or not seems to be if $eprint->get_all_documents == 0 or not.  I expect we could create an SQL query to extract this or use some code.  Obviously we could create a regular field and populate it with the use of eprint_automatic_fields.pl but the value "TRUE"|"FALSE" could be easily derived using code or SQL query instead.
> 
> We'd like to extend this virtual field a bit so that the same field can also be searched against in the advanced search.  Has anyone implemented something along those lines?  Or am I missing something that is maybe too obvious for me to see?
> 
> A discussion with a colleague of mine resulted in his suggestion that we may need to create a type of Virtualfromsql.pm where we create a virtual field which is derived from an SQL search, has anyone tried or had any experience with this kind of approach?
> 
> -Thanks,
> Brian.
> 
> Brian D. Gregg
> Solutions Architect
> University of Pittsburgh | University Library System
> Address: 7500 Thomas Blvd.  Room 129 Pittsburgh, PA 15208
> Tel: (412) 648-3264 | Email: bdgregg at pitt.edu | Fax: (412) 648-3585
> https://orcid.org/0000-0001-6541-4544
> 
> *** 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/20170413/0e2c5692/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20170413/0e2c5692/attachment-0001.bin