How to delete a kind in Google cloud datastore - google-app-engine

In the Cloud Datastore Admin console, I can only delete all entities of a certain kind. I am wondering how to delete the kind along with all its entities as well.
I am using datastore emulator as the local dev server.

After you delete all the entities of a kind, the kind will no longer appear in the Cloud Datastore Admin console. I don't recall if it is immediate. It might take 24 hours or so.

Related

What are the challenges in moving from PaaS to IaaS on GCP?

After reading available answers/comments on similar questions on this forum, it is now evident that GAE app is not straight-forward ready to be deployed on Compute engine. I fully understand that what all the managed services(mostly as APIs be it, datastore, document/index Search, memcache, cloud storage, task queues, cron jobs etc.), App Engine offered being a platform, won't be the same-fashioned accessible/integration-ready if available on Compute engine at all.
We have a 5 years old fully-grown App engine app now.
I am considering a scenario to support high-level of customization/control and adding third party softwares/middlewares to our server environment which is not possible with App engine. So if we have all solutions(Compute Engines, Container Engines etc.) other than App engine, to migrate our application to meet such requirements, what is the cost of such migration?
Need of server provisioning and configuration at Compute engines with different pricing model[Understood, should not be a problem :)]
Full or partial code rewrite to continue using the same APIs esp. Datastore, Cloud Storage, Task Queues, Cron jobs, Document Search, Memcache etc.[Need confirmation here and any reference/link to migration guide would be help!!]
Does this lead to risk of losing any managed service/API offered from App Engine? Document Search, Memcache, Task Queues, Cron jobs seem the possible candidates. Please confirm.
As per my reading, Big Query, Cloud storage, Pub-Sub APIs integration should not be much affected with such migration(Client-libraries or Rest APIs should still help!). Please confirm.
In nut-shell, We wanted it fully managed in the beginning so PaaS seemed the right choice 5 years ago. Now we want App minus platform-managed plus customized/flexible to our choice. How complicated this transition is going to be?
Full or partial code rewrite to continue using the same APIs esp. Datastore, Cloud Storage, Task Queues, Cron jobs, Document Search, Memcache etc.[Need confirmation here and any reference/link to migration guide would be help!!]
Unfortunately, some of those service only be provided on GAE, such as Document Search. But most of service can be use directly for GCP, such as Datastore, Cloud Storage. GAE Flexible Environment is much like GCP environment, so you can read this article first Migration to GAE Flexible Environment
In following articles also have some answer:
How to migrate Google App Engine Project to Compute Engine completely
Google App Engine Blobstore to Google Cloud Storage Migration Tool
Does this lead to risk of losing any managed service/API offered from App Engine? Document Search, Memcache, Task Queues, Cron jobs seem the possible candidates. Please confirm.
Yes, Document Search only available on GAE.
As per my reading, Big Query, Cloud storage, Pub-Sub APIs integration should not be much affected with such migration(Client-libraries or Rest APIs should still help!). Please confirm.
Yes, but you may need to change SDK or library. It dependency on your language and how to call those service by Rest API directly or SDK.

Best storage option for user credentials (Google Cloud ecosystem)

In the Google Cloud ecosystem, what is the canonical storage option for basic user data including login credentials?
username
password
email
etc.
Let's optimistically say my app has 100K users, and I don't want to enable social login, but might want to in the future.
I'm looking at CloudSQL and Datastore at the moment, and am unsure about the tradeoffs.
The main reason why I have been choosing Cloud Datastore in favour of Cloud SQL is the horizontal scalability of Datastore which is fully managed by Google. Since it is backed by Bigtable, you don't have to worry about scaling your instances.
Another thing you have to keep in mind is the cost model: with Cloud Datastore you pay per read/write/delete and storage. And for Cloud SQL you pay per running instance and storage. When you are starting up a website with only a few users, Cloud Datastore is very cheap, because you don't have to pay for a 24/7 running instance of Cloud SQL. When the traffic grows, it depends on the usage pattern what technology will be more cost-effective.
With Cloud SQL, you are more flexible when performing ad-hoc queries: you don't always have to add an index beforehand. And even if you do, you don't have to re-write all entities to add the entity (like it is the case in Cloud Datastore). And of course you have the obvious advantages: ACID support and a wide range of frameworks to choose from to interact with MySQL or PostgreSQL.
Keep in mind that both technologies seem similar, but the characteristics are completely different. You will encounter that when designing your Datastore dataset for scale and reading the documentation about the limits.
Finally, it might also be worth to take a look at these two products:
Cloud Firestore: the successor of Cloud Datastore, currently in Beta
Firebase Authentication: an API that handles authentication and integrates nicely with other Firebase products

Is there a way to trigger a Google Cloud Function with a Google Datastore event?

It seems like you can get events from Google Cloud Platform, but not from Google App Engine services. Why is that?
Thanks
Cloud Functions is a new service on GCP, whereas Cloud Datastore is a high query per second (QPS) service that is more sensitive to latency changes.
This means it's still early and integration with Cloud Datastore is more complex than most other systems. It's been looked into, but nothing to announce yet.
Have you looked at Datastore Callbacks? They're somewhat analogous to triggers in an RDBMS environment. For example, you could write callback methods that get invoked every time an entity of a particular Kind is put or deleted.
https://cloud.google.com/appengine/docs/standard/java/datastore/callbacks

Make an Android+ios+web app with profiles like facebook, using google cloud services

I am working on a project which needs to store profiles of people on the cloud.
Information includes multiple photos and multiple text fields. I don't need Messaging.
There is lot if confusion in the documentation provided Google Cloud Services.
I am confused about what storage services should I opt for out of the 3:
1-Google Cloud Services,
2-Google Datastore,
3-Google Cloud SQL
So the the things i need to confirm are:
0.Is there a storage limit on using Google cloud SQL?
1.Does Google Cloud Storage and Google cloud Datastore provide unlimited storage?
2.Can an Android user write data on the cloud. I heard from some where that the applications only have access to read the data and the developer needs to put the data as blob on the cloud him self when using Google Cloud Services. Is this fact true for all the 3 storage services.
3.Is the data fully 'Sharable'+'Searchable'?
In other words:
If an Android user stores data in cloud in Google Datastore(text)+Google Cloud Storage(image), can this data be accessed by another android user without any headache of permissions or authentication(after I authenticate my app/app-engine)?
4.Is it the best option to store the images in Google Cloud Storage and their URLs in Google Datastore?
5.Does all the three storage services need app-engine to work?
6.Are any limitations on each of these services?
(0) Cloud SQL has currently a limit of 250Gb.
(1) With regards to Cloud Storage, there isn't a limit you could reach.
(2) and (3) They're not created for easiness of searchability. They should be accessed through applications, that are authorized, i.e. is not a substitute to Google Drive or Dropbox.
If you're the owner of the project, you can "browse" the contents of your Cloud Storage, but it's not meant for that.
Furthermore, objects in Cloud Storage can't be modified once created. A change needs to create a new copy of the object.
(4) It's a good idea, and something is used by many developers who have their applications in Google App Engine.
(5) No, they can exist without you using Google App Engine, but as I said earlier, you'd probably need an "application" to allow your Web/Android users to interact with the data, and there's where GAE comes handy.
(6) Yes, your budget.
If you provide a more detailed use case, I could tell you what you'd need to do to get it done with the whole array of Google Cloud products.

Google Cloud Datastore vs Google App Engine

I was having a look at the new Google Cloud Datastore and looks great. But there is something I could not understand... is it supposed to substitute Google App Engine Datastore? How can I use it inside GAE? What are the differences between both of them?
I have a GAE app in Java that uses 3 entities with thousands of rows each one, and I need to do joins quite often...
The cloud datastore is the App Engine datastore, for use outside App Engine. You won't get any benefit trying to use it with your App Engine app, unless you need other external apps to also have access to the data.
You certainly won't get more efficient joins. If you really need that, perhaps you should look into Cloud SQL, which is basically a version of MySQL you can use from App Engine.
They both are the same, in fact Google App Engine can use Google Cloud DataStore as one of its way to store data, the other options include Google Cloud SQL, Google Cloud Storage. You may select among these three according to the type of data you want to store and the way you want to access them.
From your question its clear that Google Cloud SQL would be right choice as no other options provide joins for retrieving results.
Cloud SQL is nothing but MySQL(the popular open source database) running on google platform. So you can perform your regular SQL-like queries to get your results.

Resources