I have just added CloudKit to my app to sync my CoreData database between devices. It works great when pointing to Development. It creates all the records from my CoreData database in the private container on CloudKit. When I change it to point to Production, it doesn't work. I get the error:
"Cannot create new type [one of my types] in production schema"
I'm not sure if this is an issue, but it says this under my container on the Dashboard: "This container has not been deployed to Production." Since I'm only using Private database, I assume I don't have to deploy anything to Production? Or am I misunderstanding something?
I was able to solve this. It turns out I was misunderstanding something. I learned that even when using only a Private database, we still need to deploy schema changes to Production via the CloudKit dashboard.
Related
I have a nodejs/express application and an atlas mongoDB set up. I can get the data from the database to my app if it is running on local host. When I try and deploy the app as a web app through Azure, it does not work; I click the button to get/display the data but nothing happens. What is causing this issue and how do I fix it?
I figured out what was wrong. My repository did not include a web.config file at all. Having never worked with web applications or Node before, I did not know this was needed. Once I added the file and put the proper path in, the code began working as intended. I can update this post with actual code if someone wants it.
I have an app out in the App Store, and I am working on a lightweight migration (adding new attributes and new entities, not deleting anything). From extensive research, I know that I need to add a new version of my current Core Data Model for the local version of the data model. Anyone who updates their app and only uses the local data will automatically be migrated over.
However, I can not find anything about what happens when I update the iCloud schema (from icloud.developer.apple.com). Mainly, I'm concerned about users who are on older versions of the app and are using iCloud. When I update the schema in the iCloud website, will users on an older version of the app lose their current data or not be able to sync their data since their local schema will be different from the iCloud one?
Also, I'm using an NSPersistentCloudKitContainer for syncing the Core Data with CloudKit.
Any help is greatly appreciated as I do not want to mess up anyone's data!
No, their data still be on iCloud and they could continue to use your app.
When your Schema is deployed to the Production environment, you can not change types of Records or delete them, so all your changes will be done only in addition to the current Schema settings and does not affect users, which have not updated the app yet.
I had a similar question previously and was quite anxious about updating my app Schema, but everything went well - no problems for users and no data was lost.
Do not forget to initialize your new scheme from the app and deploy changes to the Production on iCloud dashboard.
You could initialize your scheme in your AppDelegate when you initialize your NSPersistentCloudKitContainer with following code:
let options = NSPersistentCloudKitContainerSchemaInitializationOptions()
try? container.initializeCloudKitSchema(options: options)
After that you could comment out these lines until the next update of Core Data model.
You could check that all changes are uploaded in the iCloud dashboard by clicking on Deploy Schema Changes - you will see a confirmation window with all the changes to the model which will be deployed.
It is also possible to change your Scheme directly in the iCloud dashboard, but it is not so convenient (unless you need to add just one Record type).
Since changes in the Schema are not affecting existing users, I usually move them to Production before I submit the app for review, but after all testing related to new Record types is done and I am not planning to change anything there.
Say I have 1 azure app which calls 1 azure api service. Now I need to update both applications to a newer version, in the most extended scale, i.e. database not compatible, api has changes to existing method signatures that are not compatible to old version invocation either. I use visual studio's publish profile to directly update. The problem I've been facing is that during the publish process, although it's only a few seconds of time, there're still active end users doing things on the web app and making api calls. I've personally seen results in such situations which are unstable, unpredictable and the saved data might be simply corrupt data.
So is there a better way to achieve some sort of 'flash update' which causes absolutely no side effect to end users? Thanks.
You should look at a different deployment strategy. First update the database, maybe with accepting null values, deploy a new API next to the current one. Validate it. Switch the traffic from current to new. Same for the website. It is a blue green deployment strategy, requires some more effort but solves the downtime or errors. https://www.martinfowler.com/bliki/BlueGreenDeployment.html
For the web app, you should use the deployment slots, deploy your new version to a staging slot and once you are ready, it is a matter of pointing the site URL to the new slot. This doesn't take anytime at all.
For the database, I believe you should freeze updates, take a backup and let the users work in readonly mode, and once you finish all your DB migration and changes, point the application to the new database and that is it.
I'm using Entity Framework with a code first model; I've got my InitialCreate migration setup and working locally, I can run code against my database context, and everything works.
But when I deploy my project to Azure, I just get a connection string error ("Format of the initialization string does not conform to specification starting at index 0.").
I can't seem to find where in the Publish dialog are the options to create the Azure database. -- Do I have to create the database separately and hook them up manually? -- If so, what exact process should I follow. Does the database need to have contents?
I thought Microsoft was making a big deal that this could all be done in a single deploy step, but that doesn't seem to be the case from my current experience.
When you publish your project in the publish dialog, there is an option for the code first migration in the Settings tab, it will automatically show your data context and it will give you the option to set the remote connection string, and this will add a section in web.config to specify the data context and the Migration class to run during the migration process.
It will also allow you to set if you want to run the code first Migration or not.
You can also take a backup from the dev and clear the data then upload it to Azure SQL DB, this way the code first data context will check at first connection and it will find the code an database the same
I have a reasonably complex Access 2013 web app which is now in production on hosted O365 Sharepoint. I would like to take a backup (package snapshot) into a test environment, and then migrate this to production once development is complete (I certainly don't want to do development on the production system!). The problem is that the snapshot also backs up all data so uploading the new package over the top of the existing package in the sharepoint app repository reverts the data to the time of snapshot as well. Alternatively, rolling back to the original snapshot if there are issues would lose all data after the new package was applied.
I can easily get a second version of the app going by saving as a new application etc but this creates a new product ID etc in the app store. We also use a Access 2013 desktop accdb frontend to hook directly into the Azure SQL database to do all the stuff that the web app can't provide (formatted reports etc) so I cant just create a new app every time without dealing with all of the credential and database renaming issues.
So my question is, does anybody know how to safely operate a test environment for Access 2013 web app development? One needs to be able to apply an updated version, or rollback to the old one if there are problems without rolling back the data. With the desktop client I can just save a new copy of the accdb file every time obviously. I dont mind creating a new instance or link to the app on sharepoint each time, however this obviously generates a totally new database (server name, db location, login id's etc) as well. You would hope there is a way to upload and replace your app without touching the data, else how else can you develop without working directly in production?
Any answers would be really appreciated.
Thanks.