...
But this Stack Exchange Post kind of helped, I had to put Account.app in my .forceignore file and then it worked. Weird.
End of the Day
Remember to pull all your source from your org then commit your git and send it to your Bitbucket in the cloud.
Next Day
When opening VS Code again and trying to log back into the scratch org it was interesting that it wasn’t just connected. All the sandboxes I am connected to are still connected when I do force:org:list. So I had to do
Code Block |
---|
sfdx force:org:open -u myusername |
But nope, it was not even that. I had not closed VS Code down, I just re-opened it, but even doing a force:source:pull it says I was not in a SFDX project. Yet my path on my terminal was set exactly to the project I was happily working in yesterday. It’s these little things that annoy just trying to get everything up and running to work. OK, this stack exchange post seemed to get me back on the right track… so it looks like it’s an issue with starting from the Trailhead project. I just changed the directory to the dreamhouse-sfdx directory and it worked from there. It’s Weird because I was not in that directory yesterday.
Data Export
Now we need to export some data… to save it to our Source… now of course I have gone and made it more complex and gone beyond the bounds of the stupidly simple examples that Salesforce give on their blog.
My data structure is now:
Account has one or more Properties
Properties may belong to one or more Accounts
Broker has one or more Properties
Properties are sold by one and only one Broker
So, Properties has two parent objects - Account and Broker. (Look, why Broker is not an Account or Contact, I don’t know - there is reasons why they would be either in the real world, but probably Account with one Contact if they are an Independent Broker).
The example for Data Tree Export only handles one relationship deep - you start with brokers and you get properties.
You can hack your Plan file as per this stack exchange post or this blog post but dammit, that blog post states you will have an issue with Record Types, and of course I have Record Types.
And data tree only handles 200 records (or you can use Shane Mc’s data tree which handles more records).
Some other options are to use regular import and export commands and ensure all your objects have ExternalIDs, or use a tool like ETCopyData or JSONBourne (for the really complex orgs).
For me for now, I’m just going to forget brokers, and manually deal with Record Types. It’s a cop out, I know, but this project is just to get me started with Scratch Orgs.
Tip |
---|
Keep a scratch text file handy to save all your commands that you are using - especially when you need to query complex soql and set up the tree data. |
Weird Things
The end goal for me would be to create a scratch org that I am happy using that has all my standard modifications in it (eg as shown in New Salesforce Org).
...