We are close to our demo.  I found a difference in production vs. my local install and this affected our data import. Even though my local install (VirtualBox on Ubuntu 14.04) has a clone of the core tenant called sdchm, the namespace that worked for things like languages and other parts was a value like: <default>urn:cspace:core.collectionspace.org:vocabularies:name(languages):item:name(zho)'Chinese'</default> need to reflect the domain of the production site: <default>urn:cspace:sdchm.bpoc.org:vocabularies:name(languages):item:name(zho)'Chinese'</default>  So, my person import needs to have these values corrected.  However, I don't want to have duplicate entries. How can I clear out person records (or object records) that we just imported? If there's not a way, we might go back to a database backup. James D. Keeline

Hi James, That domain gets picked up from the persistence/service/tenant/name element the settings.xml for your tenant. You probably didn't change it from the core tenant that you cloned on your local install. The easiest way to delete all records of a type is using SQL. You can do DE On Fri, Jun 17, 2016 at 12:16 PM, James Keeline <james@keeline.com> wrote: > We are close to our demo. I found a difference in production vs. my local > install and this affected our data import. > > Even though my local install (VirtualBox on Ubuntu 14.04) has a clone of > the core tenant called sdchm, the namespace that worked for things like > languages and other parts was a value like: > > <default>urn:cspace:*core.collectionspace.org > <http://core.collectionspace.org>* > :vocabularies:name(languages):item:name(zho)'Chinese'</default> > > > need to reflect the domain of the production site: > > <default>urn:cspace:*sdchm.bpoc.org <http://sdchm.bpoc.org>* > :vocabularies:name(languages):item:name(zho)'Chinese'</default> > > > So, my person import needs to have these values corrected. However, I > don't want to have duplicate entries. > > How can I clear out person records (or object records) that we just > imported? > > If there's not a way, we might go back to a database backup. > > James D. Keeline > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

Sorry, finishing that email: DELETE FROM hierarchy WHERE primarytype = <desired record type> The desired record type will depend on whether or not you've extended the record type. For person records it will be Person if you haven't extended, or something like PersonTenantXX if you have. Ray On Fri, Jun 17, 2016 at 1:12 PM, Ray Lee <rhlee@berkeley.edu> wrote: > Hi James, > That domain gets picked up from the persistence/service/tenant/name > element the settings.xml for your tenant. You probably didn't change it > from the core tenant that you cloned on your local install. > > The easiest way to delete all records of a type is using SQL. You can do > > DE > > On Fri, Jun 17, 2016 at 12:16 PM, James Keeline <james@keeline.com> wrote: > >> We are close to our demo. I found a difference in production vs. my >> local install and this affected our data import. >> >> Even though my local install (VirtualBox on Ubuntu 14.04) has a clone of >> the core tenant called sdchm, the namespace that worked for things like >> languages and other parts was a value like: >> >> <default>urn:cspace:*core.collectionspace.org >> <http://core.collectionspace.org>* >> :vocabularies:name(languages):item:name(zho)'Chinese'</default> >> >> >> need to reflect the domain of the production site: >> >> <default>urn:cspace:*sdchm.bpoc.org <http://sdchm.bpoc.org>* >> :vocabularies:name(languages):item:name(zho)'Chinese'</default> >> >> >> So, my person import needs to have these values corrected. However, I >> don't want to have duplicate entries. >> >> How can I clear out person records (or object records) that we just >> imported? >> >> If there's not a way, we might go back to a database backup. >> >> James D. Keeline >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> >

On Fri, Jun 17, 2016 at 1:12 PM, Ray Lee <rhlee@berkeley.edu> wrote: > That domain [i.e. the Internet domain for a tenant] gets picked up from the > persistence/service/tenant/name element the settings.xml for your tenant. > You probably didn't change it from the core tenant that you cloned on your local install. Just verified that when running our current tenant cloning tool ('ant clone-tenant') in the Application layer, the Internet domain for the new tenant to be created is: a) Required to be provided, or that Ant task will fail early-on with an error message; and b) Propagated to that location within the settings.xml file for the newly-cloned tenant; e.g. when providing 'example.com': -- <persistence> <service> <url>http://localhost:@JEE_PORT @/cspace-services</url> <tenant> <id>55</id> <name>example.com</name> -- On Fri, Jun 17, 2016 at 1:15 PM, Ray Lee <rhlee@berkeley.edu> wrote: > Sorry, finishing that email: > > DELETE FROM hierarchy WHERE primarytype = <desired record type> > > The desired record type will depend on whether or not you've extended the > record type. For person records it will be Person if you haven't extended, > or something like PersonTenantXX if you have. > > Ray > > On Fri, Jun 17, 2016 at 1:12 PM, Ray Lee <rhlee@berkeley.edu> wrote: > >> Hi James, >> That domain gets picked up from the persistence/service/tenant/name >> element the settings.xml for your tenant. You probably didn't change it >> from the core tenant that you cloned on your local install. >> >> The easiest way to delete all records of a type is using SQL. You can do >> >> DE >> >> On Fri, Jun 17, 2016 at 12:16 PM, James Keeline <james@keeline.com> >> wrote: >> >>> We are close to our demo. I found a difference in production vs. my >>> local install and this affected our data import. >>> >>> Even though my local install (VirtualBox on Ubuntu 14.04) has a clone of >>> the core tenant called sdchm, the namespace that worked for things like >>> languages and other parts was a value like: >>> >>> <default>urn:cspace:*core.collectionspace.org >>> <http://core.collectionspace.org>* >>> :vocabularies:name(languages):item:name(zho)'Chinese'</default> >>> >>> >>> need to reflect the domain of the production site: >>> >>> <default>urn:cspace:*sdchm.bpoc.org <http://sdchm.bpoc.org>* >>> :vocabularies:name(languages):item:name(zho)'Chinese'</default> >>> >>> >>> So, my person import needs to have these values corrected. However, I >>> don't want to have duplicate entries. >>> >>> How can I clear out person records (or object records) that we just >>> imported? >>> >>> If there's not a way, we might go back to a database backup. >>> >>> James D. Keeline >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >>> >> > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

  From: Aron Roberts <aron@socrates.berkeley.edu>

Knowing that I had a backup if anything went really bad, I used this query select the records to be deleted and then actually delete them. \c nuxio_defaultSELECT * FROM hierarchy WHERE primarytype LIKE '%erson%';DELETE FROM hierarchy WHERE primarytype = 'Person'; That seemed to remove them. I had difficulty getting the unique ID for the local person term list.  In Chrome even after clearing the cache multiple times I was getting an empty result.  Running against another browser (Firefox) solved the issue. Armed with the correct unique ID and the domain-specific values for the records, I made a successful import and they show up under Local Persons._____ A related issue has been observed by my PM.  An empty search against Persons >> Local Persons generates an error.  It does not do so for Storage Locations >> Local Storage, Concepts >> Associated Concepts, or catalog records.  As such, it is not an issue of having too many results as I thought.  The error displayed at the bottom of the browser is: We've encountered an error retrieving search results. Please try again:Error parsing JSONNo displayNames found!  We should be in a good position if we can resolve this issue.  I don't consider it a show stopper for the preview but would like it resolved before the training next Thursday. Have a great weekend everyone, especially all of the helpful ones from Berkeley. James D. Keeline From: Aron Roberts <aron@socrates.berkeley.edu> To: Ray Lee <rhlee@berkeley.edu> Cc: James Keeline <james@keeline.com>; Talk <talk@lists.collectionspace.org> Sent: Friday, June 17, 2016 2:35 PM Subject: Re: [Talk] Clear person records or object records? On Fri, Jun 17, 2016 at 1:12 PM, Ray Lee <rhlee@berkeley.edu> wrote: > That domain [i.e. the Internet domain for a tenant] gets picked up from the > persistence/service/tenant/name element the settings.xml for your tenant. > You probably didn't change it from the core tenant that you cloned on your local install.   Just verified that when running our current tenant cloning tool ('ant clone-tenant') in the Application layer, the Internet domain for the new tenant to be created is: a) Required to be provided, or that Ant task will fail early-on with an error message; and b) Propagated to that location within the settings.xml file for the newly-cloned tenant; e.g. when providing 'example.com': --        <persistence>                 <service>                         <url>http://localhost:@JEE_PORT@/cspace-services</url>                         <tenant>                                 <id>55</id>                                 <name>example.com</name> -- On Fri, Jun 17, 2016 at 1:15 PM, Ray Lee <rhlee@berkeley.edu> wrote: Sorry, finishing that email: DELETE FROM hierarchy WHERE primarytype = <desired record type> The desired record type will depend on whether or not you've extended the record type. For person records it will be Person if you haven't extended, or something like PersonTenantXX if you have. Ray On Fri, Jun 17, 2016 at 1:12 PM, Ray Lee <rhlee@berkeley.edu> wrote: Hi James,That domain gets picked up from the persistence/service/tenant/name element the settings.xml for your tenant. You probably didn't change it from the core tenant that you cloned on your local install. The easiest way to delete all records of a type is using SQL. You can do DE On Fri, Jun 17, 2016 at 12:16 PM, James Keeline <james@keeline.com> wrote: We are close to our demo.  I found a difference in production vs. my local install and this affected our data import. Even though my local install (VirtualBox on Ubuntu 14.04) has a clone of the core tenant called sdchm, the namespace that worked for things like languages and other parts was a value like: <default>urn:cspace:core.collectionspace.org:vocabularies:name(languages):item:name(zho)'Chinese'</default> need to reflect the domain of the production site: <default>urn:cspace:sdchm.bpoc.org:vocabularies:name(languages):item:name(zho)'Chinese'</default>  So, my person import needs to have these values corrected.  However, I don't want to have duplicate entries. How can I clear out person records (or object records) that we just imported? If there's not a way, we might go back to a database backup. James D. Keeline _______________________________________________ Talk mailing list Talk@lists.collectionspace.org http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org _______________________________________________ Talk mailing list Talk@lists.collectionspace.org http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi James, Congrats on getting super close! > We've encountered an error retrieving search results. Please try again:Error parsing JSONNo displayNames found! A thought here: because importing records via the Imports Service bypasses most of CollectionSpace's frameworks (including the data integrity checks present there), to improve performance, it's conceivable that one or more of the Persons records imported might be missing a Term Display Name, or have an invalid refName, or have some other issue that might trigger that specific error. You might start by checking your import file(s) to see if there are any records whose patterns in those and similar fields aren't clearly different than the others. Some other possible diagnostic/fixup techniques are mentioned below. Aron -- Sometimes, log entries in the Application and/or Services layer might help you identify the problematic record. Just after encountering this error, it's worth a glance in $CSPACE_JEESERVER_HOME/logs, at logs like cspace-app.log, cspace-services.log, and catalina.out, to see if you can spot the error in log entries and find out whether the CSID or any other identifying information might be present in those entries. If you've imported a total of over 10 Person records, it might also be possible to at least do a divide-and-conquer (binary-like) search in the UI to help you narrow down the likely problematic record(s), as well as identifying which records are fine. You can search on Person; e.g. https://qa.collectionspace.org/collectionspace/ui/core/html/findedit.html?recordtype=person&vocab=all&keywords= and page through the search results using the widget at the bottom of the search result until one or more pages yield that error; the problematic record(s) will be on those pages of results (although those results won't be visible due to the error). You can then compare that against your entire list of records, retrievable via the Services REST APIs (.../cspace-services/personauthorities/{authority_csid}/items), to find potential candidates for that problematic record. When you find one or more records that need to be deleted, you can delete them via the REST API, as well. If a DELETE call still fails - I've encountered one instance where that happened - you can also 'cascade delete' the record via its CSID via a command mentioned earlier in our long thread; e.g.: DELETE FROM hierarchy WHERE name='d6515434-abae-4674-a413-39438ca62ff1'; On Fri, Jun 17, 2016 at 2:49 PM, James Keeline <james@keeline.com> wrote: > Knowing that I had a backup if anything went really bad, I used this query > select the records to be deleted and then actually delete them. > > \c nuxio_default > SELECT * FROM hierarchy WHERE primarytype LIKE '%erson%'; > DELETE FROM hierarchy WHERE primarytype = 'Person'; > > > That seemed to remove them. > > I had difficulty getting the unique ID for the local person term list. In > Chrome even after clearing the cache multiple times I was getting an empty > result. Running against another browser (Firefox) solved the issue. > > Armed with the correct unique ID and the domain-specific values for the > records, I made a successful import and they show up under Local Persons. > _____ > > A related issue has been observed by my PM. An empty search against > Persons >> Local Persons generates an error. It does not do so for Storage > Locations >> Local Storage, Concepts >> Associated Concepts, or catalog > records. As such, it is not an issue of having too many results as I > thought. The error displayed at the bottom of the browser is: > > We've encountered an error retrieving search results. Please try > again:Error parsing JSONNo displayNames found! > > We should be in a good position if we can resolve this issue. I don't > consider it a show stopper for the preview but would like it resolved > before the training next Thursday. > > Have a great weekend everyone, especially all of the helpful ones from > Berkeley. > > James D. Keeline > > ------------------------------ > *From:* Aron Roberts <aron@socrates.berkeley.edu> > *To:* Ray Lee <rhlee@berkeley.edu> > *Cc:* James Keeline <james@keeline.com>; Talk < > talk@lists.collectionspace.org> > *Sent:* Friday, June 17, 2016 2:35 PM > *Subject:* Re: [Talk] Clear person records or object records? > > On Fri, Jun 17, 2016 at 1:12 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > That domain [i.e. the Internet domain for a tenant] gets picked up from > the > > persistence/service/tenant/name element the settings.xml for your tenant. > > You probably didn't change it from the core tenant that you cloned on > your local install. > > Just verified that when running our current tenant cloning tool ('ant > clone-tenant') in the Application layer, the Internet domain for the new > tenant to be created is: > > a) Required to be provided, or that Ant task will fail early-on with an > error message; and > b) Propagated to that location within the settings.xml file for the > newly-cloned tenant; > e.g. when providing 'example.com': > > -- > <persistence> > <service> > <url>http://localhost:@JEE_PORT > @/cspace-services</url> > <tenant> > <id>55</id> > <name>example.com</name> > -- > > On Fri, Jun 17, 2016 at 1:15 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > Sorry, finishing that email: > > DELETE FROM hierarchy WHERE primarytype = <desired record type> > > The desired record type will depend on whether or not you've extended the > record type. For person records it will be Person if you haven't extended, > or something like PersonTenantXX if you have. > > Ray > > On Fri, Jun 17, 2016 at 1:12 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > Hi James, > That domain gets picked up from the persistence/service/tenant/name > element the settings.xml for your tenant. You probably didn't change it > from the core tenant that you cloned on your local install. > > The easiest way to delete all records of a type is using SQL. You can do > > DE > > On Fri, Jun 17, 2016 at 12:16 PM, James Keeline <james@keeline.com> wrote: > > We are close to our demo. I found a difference in production vs. my local > install and this affected our data import. > > Even though my local install (VirtualBox on Ubuntu 14.04) has a clone of > the core tenant called sdchm, the namespace that worked for things like > languages and other parts was a value like: > > <default>urn:cspace:*core.collectionspace.org > <http://core.collectionspace.org/>* > :vocabularies:name(languages):item:name(zho)'Chinese'</default> > > > need to reflect the domain of the production site: > > <default>urn:cspace:*sdchm.bpoc.org <http://sdchm.bpoc.org/>* > :vocabularies:name(languages):item:name(zho)'Chinese'</default> > > > So, my person import needs to have these values corrected. However, I > don't want to have duplicate entries. > > How can I clear out person records (or object records) that we just > imported? > > If there's not a way, we might go back to a database backup. > > James D. Keeline > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > > >