topic Re: queryAttachments only returns one attachment when multiple exist in ArcGIS JavaScript Maps SDK Questions

queryAttachments only returns one attachment when multiple exist

GeoSolver — Tue, 01 Feb 2022 23:13:22 GMT

I have a feature service with attachments and editing both enabled. Several features have multiple attachments. When I call the queryAttachments() method on this feature layer and pass in an objectId for a feature that has multiple attachments, I only get the first one in the returned data.

This code snippet always returns only the first attachmentInfo but the feature has two attachments. Both attachments are visible in an ArcGIS Online web map that consumes this layer. They are also both visible in the data tab under Content. But again this code only returns the one.

// get all attachments for feature with objectId = 3 const oid = 3; const attachmentsByObjectId = await layer.queryAttachments({ objectIds: [oid] }); if (attachmentsByObjectId && attachmentsByObjectId[oid] { attachmentsByObjectId[oid].forEach(a => { console.log(a); }); }

Strangely, if I use Postman to query the exact same feature in the same feature service using the /queryAttachments endpoint, I get the correct number of attachments in the response data.

Some info in this URL is obfuscated for privacy, but the rest call works perfectly.

https://services.arcgis.com/<item>/arcgis/rest/services/<layerName>/FeatureServer/2/queryAttachments

And the above call returns the correct data payload including both attachments:

{ "fields": [ { "name": "OBJECTID", "type": "esriFieldTypeOID", "alias": "OBJECTID", "sqlType": "sqlTypeOther", "domain": null, "defaultValue": null } ], "attachmentGroups": [ { "parentObjectId": 3, "parentGlobalId": "", "attachmentInfos": [ { "id": 1, "name": "test001.jpg", "contentType": "image/jpeg", "size": 3299047, "keywords": "", "exifInfo": null }, { "id": 2, "name": "test002.jpg", "contentType": "image/jpeg", "size": 488852, "keywords": "", "exifInfo": null } ] } ] }

Is there a problem with my JS code, or is there some arbitrary limitation with the JS API where it will only return a single attachment per feature?

Re: queryAttachments only returns one attachment when multiple exist

Anonymous User — Wed, 02 Feb 2022 04:53:11 GMT

You are indexing your return by the oid, 3 in this case in your code that is trying to step through the results: attachmentByObject[3]. Are you parsing the return from your call correctly?

also, console.log(a) may only print once and add a counter how many times it was printed if it’s the same thing. If you are printing results, try console.log(JSON.stringify(a)) for it to print the properties of the object.

Re: queryAttachments only returns one attachment when multiple exist

GeoSolver — Wed, 02 Feb 2022 13:16:33 GMT

Thanks for the reply Jeff. I'm indexing the return by the oid 3 on purpose. The JSON structure is such that I should be getting an array of attachment objects as the value for the "3" property. Instead I only get one.

I checked the dev console for a counter next to console.log but it's only logging once. It really seems like I'm only getting a single attachment in the response.

For better visibility, I changed the code to log the entire attachmentsByObjectId object.

// get all attachments for feature with objectId = 3 const oid = 3; const attachmentsByObjectId = await layer.queryAttachments({ objectIds: [oid] }); console.log(attachmentsByObjectId);

Here is a screenshot of what's logged in the dev console in chrome:

What I should be seeing is {3: Array(2)}

Re: queryAttachments only returns one attachment when multiple exist

GeoSolver — Wed, 02 Feb 2022 13:23:39 GMT

Out of curiosity I did a quick test with a different feature. I uploaded the exact same two files as attachments to a different feature and it works. Querying attachments on that feature returns both attachments.

So....I went back to the original feature, deleted the attachment that is missing in the query responses, re-uploaded it, and now it works. Both attachments are returning in the query response for the original feature as well.

I must have had a bad upload the first time. Next time I'll experiment with the actual file uploads a bit more before blaming my code.