Jesse, You can skip the update to the 901 unless you plan to use the new subfield right away.
Upgrades are never as simple as one would like, particularly on a system where patches have been applied before they're released, etc. I highly recommend having another machine where you run PostgreSQL with a copy of your production data so that you can test the upgrade scripts before doing it for real. I also recommend becoming familiar with the build/tools/make_release script. It's used by release managers and build masters to make the release tarballs. However, with the correct options, it can be used to generate a custom DB upgrade script from any version of Evergreen to any other. I use it as a first step for our upgrades at C/W MARS. HTH, Jason On 11/15/2017 11:15 AM, Jesse McCarty wrote: > Dan, > > > > Any assistance with creating a file that will break up the update task > would be greatly appreciated. We ended up deciding to hold off on > upgrading until 3.0 was released and we have a running test server with > semi current data in it. But, after doing all the re-ingests and other > associated DB upgrades throughout the various DB scripts, running the > update biblio.record command took something like 4 days. I’m not sure > how the 901 field is used within our library, but I would like to ensure > the upgrade is done completely so there are no surprises as well as get > everything ironed out in the testing environment so I know exactly what > to expect when we upgrade the production system to the 3.0 series. > > > > Thank you again, > > > > Jesse McCarty > > City of Burlington > > Information Systems Technician > > > > *From:*Open-ils-general > [mailto:open-ils-general-boun...@list.georgialibraries.org] *On Behalf > Of *Daniel Wells > *Sent:* Wednesday, April 19, 2017 7:38 PM > *To:* Evergreen Discussion Group > *Subject:* Re: [OPEN-ILS-GENERAL] Upgrading from 2.10 to 2.11 error > questions > > > > Hello Jesse, > > > > For your first issue, it appears you have some kind of encoding problem > in some of records. This is very common for any record with foreign > characters. Without getting into too much detail, MARC records are > generally supposed to use UTF8 encoding (a modern, universal encoding) > or MARC8 encoding (an older, library-centric standard). Records will > commonly say they use one encoding but have characters from the other, > or use characters from an entirely different, unsupported encoding (e.g. > Latin 1). I would recommend you try to sort these out eventually, but I > don't think you are doing any additional harm here. > > > > For the 901s update, this update is kinda brute-force, so there is a > chance you will run into table lock problems if anyone else tries to > update the biblio.record_entry table while this is running. The > biblio.record_entry table doesn't get updated during normal OPAC and > circ operations, so if you can avoid saving records, you should be able > to run it while live. A safer option (which we typically take) in > situations like this is to actually generate a file where every update > is a separate command (UPDATE biblio.record_entry SET marc = marc where > id = 123; UPDATE biblio.record_entry SET marc = marc where id = 124; ... > etc.). Such a setup lets it plod along without holding onto multiple > rows as the work is done. Let me know if you need more guidance in > creating such a file. > > > > Also, that upgrade step comes from this feature > addition: https://bugs.launchpad.net/evergreen/+bug/1307553 . Unless > you actively plan to take advantage of this new source subfield $s, you > can delay this entire command until a more convenient time. It won't > affect any normal operations to not have that subfield populated. > > > > Sincerely, > > Dan > > > > On Wed, Apr 19, 2017 at 4:22 PM, Jesse McCarty <jes...@burlingtonwa.gov > <mailto:jes...@burlingtonwa.gov>> wrote: > > Hello Everyone, > > > > We are preparing for our spring upgrade to Evergreen, moving from 2.10.3 > to 2.11.3 and ran into one little bump. As part of the DB upgrade, there > is an update setting the 901$s for bib records. First question, as seen > in the attached screen shot, this threw a bunch of ‘no mapping found > for….’ Errors. Can this be safely ignored and proceed with running the > system after upgrading with no issues (we haven’t seen any issue in our > testing)? > > > > The second, this update seem to take longer than 24 hours. With that in > mind would we be able to process the entire upgrade, then use Evergreen > in daily production while this DB update finishes in the background? Or > does this need to be 100% complete before allowing library’s connection > to the system? > > > > Thanks in advance, > > > > Jesse McCarty > > City of Burlington > > IT Technical Assistant > > > > >
