I have followed this tutorial and added my database. I did target both my app and my extension. From my app I can SELECT, INSERT, DELETE and UPDATE to the database. I want both my app and extension to share the same database. So I add information in my app and then show that information in the extension.
As it works now (I have tested) the app has one instance of the database and the extension has one instance. I have only added one db. Anyone got a clue why I have two instances of my database and why I can´t access the data added from the app in the extension?
Apps and their extensions are separate processes, so iOS sandboxing normally means they can't touch each other's files. The page you reference doesn't appear to address this in any way.
If you want to use the same SQLite file in both your app and the extension, you need to configure the "app groups" entitlement for both of them. That sets up a new directory that both of them can access, and you put your SQLite file there. You find this directory by using the containerURLForSecurityApplicationGroupIdentifier: method on NSFileManager.
It's not clear to me whether the GitHub project you're using will make use of app groups. There's no other way to share your SQLite file, though. If that project doesn't use app groups, you'll need to either fix it so that it does or stop using it.
Related
I have a WP website running on Azure app service, I want to clone it because my website is online but I want to experiment on it (So I want to clone it, leave one online and experiment with the clone), There is a service to clone my app inside azure but it is paid, it is there other way to clone the content (plugins and configuration) of my wp app service to put it in another wp app service?
There are two different options you can use to copy your site;
1) Copy the files and database onto the new webspace
This method is good if you have access to all your files and the database for your site. You simply copy the files over to the other webspace and export the database. This link will give you more information on this method - https://www.wpexplorer.com/migrating-wordpress-website/
2) Using a plugin to do it for you
There are several plugins you can use that will do the above for you and will automatically create a backup of your site including the database so that you don't have to do anything. Might I suggest this plugin, I've used it myself so I know it's reliable and should do the trick - https://en-gb.wordpress.org/plugins/all-in-one-wp-migration/
It also has a feature that allows you to change any old URLs to the new URL which will save you a bit of time.
I hope this provides enough information for you to successfully transfer your site over.
I am using a Custom Domain for a Google Application project. I have multiple projects and I use the same domain for each, although only one mapping is active at any time. Historically this has been as simple as Verifying the domain on the latest project and then Adding the domain. The domain has then automatically switched to the new project.
I have not used this approach for some months and when I tried it recently I got the messages
www.xxxxx.com is already mapped to a project.
xxxxx.com is already mapped to a project.
Research on StackOverflow suggests the use of the following command
gcloud beta app domain-mappings create xxxxx.com
This does look the right thing to do, unfortunately the response to the command is:
ERROR: (gcloud.beta.app.domain-mappings.create) App [aaaaaa] is the subject of a conflict: Domain 'xxxxx.com' is already mapped to another application. You must delete the existing domain mapping before you can re-map the domain, or you may specify 'DomainOverrideStrategy.OVERRIDE' on the request to force overwrite the existing mapping. Domain 'xxxxx.com' is currently mapped to an application on which you do not have permissions.
I do not want to use the delete approach since there will be a gap in service before the re-map. I would like to use the OVERRIDE option but I cannot work out how to add it to the gcloud command and I cannot locate any documentation.
Update 6Nov17.
In the absence of an answer I have used the delete approach and it worked as expected. The re-map was possible immediately after the mapping was deleted for the current app. Unfortunately for some users access to the web page was not possible, or error messages were returned, for a while. After about 10-15 minutes normal service was resumed. For my web site a gap of 10-15 minutes is manageable. This will not be true for many sites and I anticipate that Google Cloud will tidy up this procedure before it exits Beta.
If for some reason it is not possible to access the current app to delete the mapping then I guess deleting the app's subdomain information at the domain registrar will have the same effect, although it may be difficult to predict when the delete of the associated mapping will happen.
On the plus site the new automatic SSL provision worked flawlessly.
Q1: Where do you think is the right place to put a SQLite database file (database.sqlite) in Azure Web App file system? For example:
D:\home\data\database.sqlite
D:\home\site\database.sqlite
D:\home\site\wwwroot\database.sqlite
other?
Q2: What else should be taken into consideration in order to make sure that the database file won't be accessible to public users as well as not being accidentally overwritten during deployments or when the app is scaled up/down? (The Web App is configured for deployments from a Local Git Repository)
Q3: Where to learn more about the file system used in Azure App Service, the official source URL? E.g. how it's shared between multiple VMs within a single Web App, how does it work when the App is scaled up/down, what's the difference between D:\home (persistent) vs D:\local (non-persistent)...
Note that SQLite does not work in Azure Blob Storage, so that one is not an option. Please, don't suggest alternative storage solutions, this question is specifically about SQLite.
References
Appropriate Uses For SQLite
In a Web App, your app is deployed to d:\home\site\wwwroot. This is the area where you may write files. As an example, the ghost deployment writes its SQLite database to d:\home\site\wwwroot\content\data\ghost.db. (easy to see this, if you open up the kudu console via yourapp.scm.azurewebsites.net):
This file area is shared amongst your web app instances. Similar to an SMB file share, but specific to web apps (and different than Azure's File Service).
The content under wwwroot is durable, unless you delete your app service. Scaling up/down impacts the amount of space available. (I have no idea what happens if you scale down and the smaller size has less disk space than what you're consuming already).
I would say the best location would be app_data folder in the site/wwwroot folder. Create the folder if it doesn't exist.
Web Apps can connect to storage accounts so you can in fact use blob storage and connect that to your web app. So in terms of learning more about it then you need to be looking at the appropriate page of documentation.
In your Web App settings you can then select which storage account to use. You can find this under Settings > Data Connections where you can select Storage from the drop down box.
In my GWT application, a 'root' user upload a specific text file with data and that data should be available to anyone who have access to the app (using GAE).
What's the classic way to store a data that will be available to all users? I don't want to use any database (objectify!?) since this is a relatively small amount of information and it changes from time to time by root.
I was wondering if there was such static MAP on the 'engine level' (not user's session) that this info can be stored (and if the server is down - no bigi, root will upload again)
Thanks
You have three primary options:
Add this file to your /war/ directory and deploy with the app. This is what we typically do with all static files that rarely change (like .css file, images, etc.) This file will be available to all users, whether they are authenticated or not.
Add this file to your /war/WEB-INF/ directory and deploy with the app. This file will be available to your server-side code, so you can read it on the server-side and show to a user. This way you can decide which users can see this file and which users should not have access to it.
Upload this file to Google Cloud Storage. You can do it through an app, or you can simply upload it manually to a bucket using a GCS console or gsutil command-line tool. Then you simply provide a link to your users. The advantage of this option is that you do not have to redeploy your app when a file changes.
The only reason to go with the first two options is to have this file under version control. If you don't need that, I would recommend going with the GCS option.
I am working on Restful Web application. I am maintaining different project for web client code and Google app engine server code.
When ever i made changes in the client code, i rebuilt the client code and places inside the war folder of server project through build scripts.
Here i dont want to place all files directly to war folder and i wanted to put them under folder called 'Publish' for better maintainence. How can do it?
Is there any better way to maintaining client code and Google app engine server code?
The structure also works well for Mobile application in future.
I am still new to this too, but there is versioning. If you change the version number in your project manifest file, it does not become the default (i.e., visible to your original public URL). It is public and accessible for you to test. When you are ready to "publish" just switch the new version to be the default. Use the Manage section of the Dashboard and set the Version to be the default when you are ready.
To test any of the earlier versions, you access through the Manage and click on the specific version. I don't know if the persistent storage is versioned with this same mechanism -- I can image problems if you have a huge DB.