search

eltoroit / ETCopyData

SFDX Plugin to populate your scratch org and/or developer sandbox with data extracted from multiple sObjects.
113 stars 23 forks source link

Need the ability to copy between orgs with/without namespacing #15

Closed bbuffing closed 5 years ago

bbuffing commented 5 years ago

I love this plugin, been so valuable! However running into an issue where I cannot copy data from a non-namespaced sandbox/scratch org to a namespaced one (as the namepaced org objects would have a prefix). It would be very helpful for ISV development if we could provide a namespace parameter for the orgSource and orgDestination so that we can copy between non-namespaced/namespaced, or even two orgs with different namespacing. Thanks!

eltoroit commented 5 years ago

Thanks for your input, namespaces was something g that I did not considered before. Guess that it could discover the namespaces while checking for the schema

eltoroit commented 5 years ago

How do you enable namespaces on a scratch org to test this?

OscarScholten commented 5 years ago

@eltoroit afaik you cannot create a new namespace just for a scratch org. I'm at an ISV as well, we create our scratch orgs using the same namespace as our packaging org. For unlocked packages it seems to be possible to create a namespace if you have a Dev Edition org: https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_create_namespace.htm

OscarScholten commented 5 years ago

@bbuffing can you tell a bit more about your workflow? As I mentioned in my previous comment, I'm working at an ISV as well. We are developing a 1st gen package, so when we spin up a scratch org for development, we create it using the same namespace as our packaging org and ETCopyData works just fine. I have experimented with creating scratch orgs with no namespace and installing our package into it for testing purposes, which works just fine too. I have not tried to use ETCopyData to ingest data into a scratch org without a namespace, but I'd expect that to work ok too. Our config file contains the explicit names, so with the namespace prefix.

Can you tell a bit more why you'd deploy your code sometimes with, and sometimes without the context of the namespace?