Images remain in old dataset after import without asset migration flag

29 replies
Last updated: Aug 25, 2021
I just tried to do a dataset import, but images are still located in old dataset. I did not use the “--allow-assets-in-different-dataset” option. Is this expected behavior?
AI Update

Yes, this is expected behavior! When you export a dataset using sanity dataset export with the --raw flag and then import it to a different project ID or dataset name, you'll encounter this error.

Why This Happens

The imported documents would reference assets that exist outside of their own dataset. This creates a problematic situation because if you delete an asset from the source dataset, you'd end up with a "loose" asset document in the target dataset that points to a file that no longer exists.

The Solution

Don't use the --raw flag when exporting if you plan to import to a different dataset or project. Without --raw, the export will include all the assets from the source dataset, ensuring they're properly copied to the target dataset during import:

sanity dataset export production backup.tar.gz
sanity dataset import backup.tar.gz new-dataset

This way, your assets will be physically present in the new dataset rather than just referenced from the old one.

The Rare Exception

In very rare cases where you specifically want assets to reference URLs from a different dataset, you can use the --allow-assets-in-different-dataset flag when importing:

sanity dataset import backup.tar.gz new-dataset --allow-assets-in-different-dataset

However, this is generally not recommended unless you have a specific use case that requires it, as it creates the dependency issue mentioned above.

For more details, check out the official documentation on this error and best practices for backing up and restoring datasets.

Show original thread
29 replies
Full command used:
$ npx sanity dataset import data/bak/development_20210825.tar.gz production --replace --replace-assets
✔ [100%] Fetching available datasets
✔ [100%] Reading/validating data file (127ms)
✔ [100%] Importing documents (3.19s)
✔ [100%] Importing assets (files/images) (1m 11.82s)
✔ [100%] Setting asset references to documents (4.35s)
✔ [100%] Strengthening references (1.45s)
Done! Imported 112 documents to dataset "production"
Would love to use the new copy and alias functions, but apparently I need next-level account for that. 😞
Full command used:
$ npx sanity dataset import data/bak/development_20210825.tar.gz production --replace --replace-assets
✔ [100%] Fetching available datasets
✔ [100%] Reading/validating data file (127ms)
✔ [100%] Importing documents (3.19s)
✔ [100%] Importing assets (files/images) (1m 11.82s)
✔ [100%] Setting asset references to documents (4.35s)
✔ [100%] Strengthening references (1.45s)
Done! Imported 112 documents to dataset "production"
Hey User, can you clarify what you mean when you say images are still located in the old dataset?
Full command used:
$ npx sanity dataset import data/bak/development_20210825.tar.gz production --replace --replace-assets
✔ [100%] Fetching available datasets
✔ [100%] Reading/validating data file (127ms)
✔ [100%] Importing documents (3.19s)
✔ [100%] Importing assets (files/images) (1m 11.82s)
✔ [100%] Setting asset references to documents (4.35s)
✔ [100%] Strengthening references (1.45s)
Done! Imported 112 documents to dataset "production"
I’m looking at production dataset, but image paths point to ‘development’ dataset. In some cases, I load the full URL from sanity, and this is fine. But, in one place, I am just grabbing asset ID in my API, and when I place that in context of production dataset to build image path, it comes up 404.
I can see images in the studio while looking at production dataset. Opening image in new window shows it is in development path.
I first encountered this, and then re-ran the import with “replace-assets”. Thought that might fix it. But, no luck.
This also begs the question of what will happen to those images if I delete the development dataset.
Got it. I think what you’re running into is covered in the gotcha in the docs here . You’ll have to reshape your data in this case.
Got it. I think what you’re running into is covered in the gotcha in the docs here . You’ll have to reshape your data in this case.
I do not understand this. Sorry. Can you please explain?
I do not understand this. Sorry. Can you please explain?
I definitely made some new data models. Trying to cleanly push things to production. I see the bit about images tied to datasets. Question is how to migrate them.
“Make sure to bring your assets along for the ride.” is the suggestion in the “gotcha”. How does one do this?
They are present in my export. And the import tool says it re-created assets.
I assumed that the “--replace-assets” (Skip reuse of existing assets) option would solve this for me.
I’m curious if the new dataset copy and alias exhibits this same behavior. Trying to figure out what the proper approach is here. Thanks,
user M
for looking into this.
Hmm, I’m trying to replicate the behavior you’re getting, but it’s not happening on my end. Can you pull up the asset in Vision by running the following query:
*[_id == "<your-image-id>"]{
  path, 
  url
}
Oh and double check that you’ve chosen the right dataset from the drop down in the top-left of the plugin.
I deleted my production dataset, re-created, and imported from my export file to this new dataset without extra options on command line. This time, I think it worked. Rebuilding front-end now to confirm.
I deleted my production dataset, re-created, and imported from my export file to this new dataset without extra options on command line. This time, I think it worked. Rebuilding front-end now to confirm.
Let me know how it goes!
Thank you for the support. I think Sanity is behaving. I have a rather complicated setup with Sanity GraphQL stitched into another GraphQL server and CDN URL’s proxied through CloudFront. Many layers of cache to disrupt things.
Currently, getting a 404 when trying to access a specific image, though. It’s like the 404 is stuck in image CDN cache or something.
Currently, getting a 404 when trying to access a specific image, though. It’s like the 404 is stuck in image CDN cache or something.
Changing the params slightly makes it work. strange.
(probably because I was trying to load this image before it existed in the right “dataset”) Now it is there, and CDN doesn’t realize it?
will add a dummy param to my images to bust this cache. thanks, again.
user M
Much love to the Sanity crew. And, yay for conditional fields. Gratitude.

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?