[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.


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 )
        } else {

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?


Brian D. Gregg
Solutions Architect
University of Pittsburgh | University Library System
Address: 7500 Thomas Blvd.  Room 129 Pittsburgh, PA 15208<https://maps.google.com/maps?q=7500+Thomas+Blvd,+Pittsburgh,+PA&hl=en&sll=41.117935,-77.604698&sspn=7.662465,13.73291&oq=7500+Tho&t=h&hnear=7500+Thomas+Blvd,+Pittsburgh,+Pennsylvania+15208&z=17>
Tel: (412) 648-3264 | Email: bdgregg at pitt.edu<mailto:bdgregg at pitt.edu> | Fax: (412) 648-3585

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20170413/2b0fd492/attachment.html