Thanks for all the information and code you have provided, I will now report this to the catalogers group.
BTW, since I am not too comfortable yet with the process and deadlines being used for 2.5, is there anything I can do to help make sure it makes it to EG 2.5? Just wondering. Thanks again, Yamil On Jul 3, 2013, at 9:47 AM, Mike Rylander <[email protected]> wrote: > On Mon, Jul 1, 2013 at 3:09 PM, Yamil Suarez <[email protected]> wrote: >> Mike, >> >> My catalogers are very happy with the results of your fix. Though I think I >> misunderstood what you were suggesting when dealing with production data. I >> ended up doing a test on production data that was copied onto a test server. >> >> Would it be hard to port this code for older versions of EG? Thankfully, we >> are on 2.4 so I would like to add this to my production server sooner than >> later. >> > > If you're fine with reingesting your authority records, you can toss > the changes on anything 2.2+, I believe. Certainly 2.4 is fine. My > understanding is that there's general community consensus against > requiring any reingest within a release, so it probably won't get into > a 2.4.x release, but it'll work fine. > > --miker > >> >> Here are some sample screenshots of a system with and without Mike's fix… >> >> 1) Search for subject authorities: Jazz >> >> - without fix >> http://www.flickr.com/photos/98246313@N05/9184401009/ >> >> - with fix >> http://www.flickr.com/photos/98246313@N05/9186620516/ >> >> >> >> 2) Search for subject authorities: Jazz France >> >> - without fix >> http://www.flickr.com/photos/98246313@N05/9186620492/ >> >> - with fix >> http://www.flickr.com/photos/98246313@N05/9184400967/ >> >> >> >> 3) Search for author authorities: Bach >> >> - without fix >> http://www.flickr.com/photos/98246313@N05/9184401093/ >> >> - with fix >> http://www.flickr.com/photos/98246313@N05/9184401065/ >> >> >> Thanks, >> Yamil >> >> >> On Jun 27, 2013, at 4:02 PM, Mike Rylander <[email protected]> wrote: >> >>> Yamil, >>> >>> First, and most importantly, skip step 1 as that's bib-only. >>> >>> Then replace references to biblio.record_entry with >>> authority.record_entry in steps 2-4, and proceed. >>> >>> Also, please do test that on non-production data first! >>> >>> Let us know if that goes well for you. >>> >>> --miker >>> >>> >>> On Thu, Jun 27, 2013 at 3:31 PM, Yamil Suarez <[email protected]> wrote: >>>> >>>> On Jun 25, 2013, at 4:41 PM, Mike Rylander <[email protected]> wrote: >>>> >>>>> On Tue, Jun 25, 2013 at 4:26 PM, Yamil Suarez <[email protected]> wrote: >>>>>> Mike, >>>>>> >>>>>> Thanks for looking into this. Can you or anyone else tell me if I can >>>>>> just re-declare the two updated stored procedures (see below) and >>>>>> re-ingest the auth records on my test server to see the code in action? >>>>>> I guess I can just build a new test VM, but I want to know if I have >>>>>> another option. >>>>>> >>>>> >>>>> That would be a great test. Just make sure that you enable the >>>>> force_on_same_marc internal flag. >>>>> >>>>>> Also, I made a mistake in my example when I placed the "Jazz England" >>>>>> auth record at the bottom. Thanks for catching that Mike. >>>>>> >>>>> >>>>> Good. I'm glad we were on the same page all along! >>>>> >>>>> --miker >>>> >>>> >>>> Mike, >>>> >>>> Before I do the re-ingest I wanted to run a few things by you or others. >>>> Here I am pasting some re-ingest instructions I put together from >>>> information I got form you over time. Though I will replace >>>> "biblio.record_entry" for "authority.record_entry" in the instructions. >>>> >>>> I am not sure how to "enable the force_on_same_marc internal flag," though >>>> these instructions might do it already. >>>> >>>> Also, my understanding is that these instructions are supposed to be >>>> designed to allow me to run re-ingest while still allowing the EG server >>>> to be usable by patrons by allowing batching, etc. In this particular case >>>> I am using a tests server so I can be as aggressive as I want. Is there a >>>> different way I can use to get the re-ingest done faster than this >>>> approach? >>>> >>>> >>>> ------------------- >>>> 1) remove the browse data >>>> TRUNCATE metabib.browse_entry_def_map CASCADE; >>>> >>>> >>>> >>>> >>>> 2) select the bib ids into a file. From within psql: >>>> >>>> =# \t >>>> =# \o /home/opensrf/mass_re-ingest/reingest_bib_ids.txt >>>> =# select id from biblio.record_entry where not deleted and id > 0; >>>> =# \q >>>> >>>> >>>> >>>> 3) Then, from the shell: >>>> >>>> ~$ awk '{print "update biblio.record_entry set id = id where id = " $1 >>>> ";"}' < reingest_bib_ids.txt > reingest.sql >>>> >>>> Then, edit /tmp/reingest.sql to add the following at the top: >>>> >>>> UPDATE config.internal_flag SET enabled = TRUE WHERE name = >>>> 'ingest.reingest.force_on_same_marc'; >>>> >>>> >>>> >>>> >>>> and then the following at the bottom: >>>> >>>> UPDATE config.internal_flag SET enabled = FALSE WHERE name = >>>> 'ingest.reingest.force_on_same_marc'; >>>> VACUUM ANALYZE; >>>> >>>> >>>> >>>> 4) the opensrf user >>>> psql -d evergreen -U evergreen -f reingest.sql >>>> >>>> >>>> ------------- >>> >>> >>> >>> -- >>> Mike Rylander >>> | Director of Research and Development >>> | Equinox Software, Inc. / Your Library's Guide to Open Source >>> | phone: 1-877-OPEN-ILS (673-6457) >>> | email: [email protected] >>> | web: http://www.esilibrary.com >> > > > > -- > Mike Rylander > | Director of Research and Development > | Equinox Software, Inc. / Your Library's Guide to Open Source > | phone: 1-877-OPEN-ILS (673-6457) > | email: [email protected] > | web: http://www.esilibrary.com
