Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the CollectiveAccess support forum! Here the developers and community answer questions related to use of the software. Please include the following information in every new issue posted here:

  1. Version of the software that is used, along with browser and version

  2. If the issue pertains to Providence, Pawtucket or both

  3. What steps you’ve taken to try to resolve the issue

  4. Screenshots demonstrating the issue

  5. The relevant sections of your installation profile or configuration including the codes and settings defined for your local elements.

If your question pertains to data import or export, please also include:

  1. Data sample

  2. Your mapping

Answers may be delayed for posts that do not include sufficient information.

Import map that works with Providence 1.7.1 is not working with 1.7.5

edited February 1 in Troubleshooting
I am trying to import data to update valuations of object. I keep getting these 3 errors with each record:

(2018-01-31 09:34:34) [2017.66.8] Failed to add value for valuation; values were valuation_types = comparable_value; valuation_notes = Artist's Retail Value; value_price = 400; appraiser = 1652; _related_related = ; valuation_date = 12/7/17; locale_id = 1: Entity id 1652 is not valid for element appraiser
(2018-01-31 09:34:34) [2017.66.8] Failed to add value for examination_container; values were examination_condition = good; examination_agent = 109; _related_related = ; examination_date = 11/30/2017; examination_description = Unfinished print. "This work remains unfinished since I no longer had access to a large bed Litho/etching press"; locale_id = 1: Entity id 109 is not valid for element examination_agent
(2018-01-31 09:34:34) [2017.66.8] Failed to add value for dimensions; values were dimensions_height = 30 1/4 in; dimensions_width = 22 1/4 in; dimensions_depth = 0; Type = sheet; dimensions_entity = 109; _related_related = ; dimensions_date = 11/30/2017; locale_id = 1: Entity id 109 is not valid for element dimensions_entity

Attached is a screen capture of the import map covering the three fields generated the errors. These are existing entities--1652 is an artist and 109 is Museum staffer. Both were part of the original data import when we started at 1.7.1. We are now at 1.7.5. 

If I change the map to skip the entity row, I don't get an error. What does 'locale_id = 1: Entity id 109 is not valid for element appraiser' mean?
What changes do I need to make to our map--seems like it is an issue with the entity splitters? 
If I need to rewrite these splitters, can you provide an example or direct me to the documentation please? 
1234 x 475 - 156K


  • Would there be any issue rolling it back to 1.7.1 for now?
  • I don't think this issue has to do with the update. If the examination "agent" is configured as an entity 'reference' then this is a really common (and pesky) issue that I also run into from time to time.

    Basically, the entities need to exist prior to import (which you say they do, so that's good) and the Source data needs to match the Entity identifier exactly. My guess is whatever is in your source data doesn't match the entity idno even while the Name might.

    Another thing that is kind of annoying with mapping to Container elements is that if one sub-element throws an error, the entire Container gets nuked. This is why everything is getting skipped because of the entity id error.

    I'd say you're almost better off configuring the agent elements as text, or just be really careful about pre-importing the Entities with identifiers.
  • Jonathan: Thanks for your reply. Just to be clear are you saying it is better to NOT to relate an agent entity with the data captured like a measurement, condition report, or valuation?

    Why does it work in 1.7.1 but does not in 1.7.5? 

    You all posted: 
    @bowbot_twitter What are you mapping to entity_id? How matching is performed on those values has changed somewhat in the past few versions.
    The error means simply that "120" doesn't match any entities. Is it meant to be an actual entity_id? Or an idno?

    What does this mean: How matching is performed on those values has changed somewhat in the past few versions.

  • It's not necessarily better - I'm just saying that importing to entity references (as opposed to relationships) within Container elements can be a pesky task.

    As far as this has anything to do with versioning, I apologize that I can't be of help on that front. I have however experienced this same error and the solution is to ensure that your source data matches up with the entity identifiers of pre-existing entity records.
  • edited February 6
    This is why I think it may be more than finicky data formatting: I went back and ran dry-run imports in 1.7.5 of existing dimensions data, that I know will import in 1.7.1, where the instance has all of the entities pre-imported, and it gives me the same errors. If I dry run in 1.7.1 there are no errors.

    I can provide a profile, map and data via email if you would like to review.
  • edited February 7
    Jonathon--any more thinking here based on my last comment?
  • Not at the moment. If you post your mapping and sample data and I can take a look at it as when I have time.
  • Emailing you the files now.
  • Hi @bowbot, the problem is those entitySplitters you have on the mapping lines for appraiser, examination_agent, and dimensions_entity. If you remove them, the import will work as expected.

    Using the profile, mapping, and sample data you sent me, I have verified that this works on version 1.7.5.

    appraiser, examination_agent, and dimensions_entity are actually configured as "references" - they're not full relationships (with relationship types). The entitySplitters only deal with relationships, so they were causing some odd matching behavior on the references mappings.
  • Hi @jonathan Thank you for reviewing the files I sent you. If I understand you correctly, I need something like this for each reference to make an actual relationship--in this case 'dimensions_entity'

    "relationshipType": "measured_by",
    "entityType": "^2",
    "attributes": {
    "idno": "^1",
    "entity_category": "^3"
  • @bowbot,

    No, you do not need anything in the refinery or refinery parameters columns. The entitySplitter and parameters you had were causing the mapping to fail.

    It should just be a straight mapping from source 59 to ca_objects.dimensions.dimensions_entity. That's it.

    This is based on the assumption that you are pre-importing the entities, and that the values in your Source data (in columns 59, 62, and 68) match the values in ca_entities.idno.

    I tested this and confirmed that it works with your mappings/data/profile in V1.7.5
  • edited February 13
    Ok. And the entity will be related to the condition, value, or dimensions data?
  • The source values will be imported to their target fields according to the mapping, based on the criteria I cited in my previous post.
  • As plaintext or as a relationship between the object and the entity?
  • As a reference. The datatype for those fields as you know is set up as 'Entities' - not 'Text'. A reference is a link between two records (an object and an entity) without a full-on relationship type or any other interstitial data. It is used in cases where Container elements need to reference an Entity record (you can't have relationships bundles inside container elements, hence the need for references). Try out the mapping once you have removed the splitters and see how it works.

  • @jonathan Thank you for your patience, I can be obtuse at times. I  modified the import and there were no errors on the dry run. I think I understand now what is happening--can you confirm:

    Because the fields 'appraiser', 'examination_agent', and 'dimensions_entity' are declared as entity fields for capturing an entity name--and it needs to be their idno. As long as the entity is in the system, they will automagically relate the appraisal, condition, or dimensions with the entity captured in the import. If they are not an already existing Entity, it will kick an error until one is created.

    If yes we will modify the workflow accordingly.

    1237 x 412 - 141K
  • Hi Matt, yes that is correct.
Sign In or Register to comment.