We are going to evaluate a possibility of using OpenStack Swift as a storage for several TBs of user-generated content. Our users are mostly e-commerce sites and we have a business need to update all objects related to a particular e-commerce site at once.
It looks like there is an API call to create a number of objects at once but we were unable to find anything relevant to bulk update. Is it still possible to perform atomic group updates in Swift somehow?
Related
Currently, on my cloud project, I have one database which contains kinds. My question is it possible to create another database that can have different kinds?
Illustration for current database
Currently, it is not possible to create another Datastore database in a single project. A workaround could be using separate projects and adding an authorized IAM user or service account to both projects in order to access both in their respective projects.
Also, maybe a multi tenancy strategy may allow you to customize data values for each tenant, while keeping the same data schema for all of them.
There are multiple companies using one application. So I want to have, or know if this is the best way, to create a project for each company, all this with the Firebase API, to create everything programmatically. But I think this is too difficult to do and get that structure. The truth is that the documentation about the Rest API to create projects is not very clear and I am getting lost. One of the things that I want to structure projects like this is to know how much use is made of each project, calculate requests and use of storage. But I don't know if there are other ways to do this.
It's not possible to create a new project for Firebase using the Firebase API, what is possible is to list projects, and create/list apps within an existing project using the Firebase Management API.
For monitoring usage, you can use Cloud Monitoring to assess the usage of each individual app, per service.
For example, if I wanted to use the functions.auth.user().onUserCreate() trigger, is there any way to make it trigger different functions for different apps that are all in the same Firebase project? Is the only way to fix this to create separate Firebase projects for each app? The issue with that is that I need them to access the same database.
It's not possible to know in a Cloud Functions trigger which app a user used when they created their account. Firebase Auth accounts don't have a sense of "ownership" with respect to multiple apps per project. All apps in a project share the same users with the same permissions.
What you can do instead is have each app write something unique in your database after the account was created, then use that to determine what that user should do later on. Either that, or use different projects if your apps don't actually need to share the same set of users.
The only possibility that I think that might help you is organizing your Cloud Functions in different files, which will be then loaded per project. So, for example, in your Project Alpha, it will run the Cloud Functions from the foo.js file, while in the Project Beta, it will run the functions from the bar.js and the same logic for other projects and Cloud Functions.
This way, even though all users are sharing the same database, it will trigger the function based in the file that you requiring in your application. You can check for tips in organizing your Cloud Functions in multiple files and calling them individually, in this official documentation here:
Organize Functions
I believe this way might work for you, so, I would recommend you to check the documentation and give it a try splitting the functions in multiple files and calling each specific files, on their specific applications only.
Let me know if the information helped you!
This is in relation to the question here: Google Cloud / Firebase Functions, handling dependencies per function
So, to manage dependencies better, is it allowed to divide the functions to as many projects as we see fit?
This would create one "master" project, that contains the data in database and storage + the projects that are otherwise empty, but contain only certain functions.
Thins of the following projects: My Awesome App, My Awesome App Stats Api, My Awesome App Admin Api etc.
It depends on what kinds of functions you're writing.
If you want to write database triggers, they have to be in the same project as the database that's receiving the writes. You can't have a second project respond to writes from the database in the first project.
If you want to write HTTP triggers, you can init the admin SDK to point to different projects for querying and such.
I don't particularly see any need to "shard" your functions like this in a production environment. Cloud Functions will scale your functions as needed to handle the load, and having different functions in different projects shouldn't make a difference in that respect.
I'm new to Azure and started an Azure Mobile App Quick-Start (.NET) project.
I'm studying on this blog wrote by Adrian Hall:
https://shellmonger.com/2016/05/09/30-days-of-zumo-v2-azure-mobile-apps-day-18-asp-net-authentication/. However, I've been confused by the explanation saying that:
Since this is Entity Framework, I would normally need to do an Entity
Framework Code First Migration to get that field onto my database. You
can find several walk-throughs of the process online. This isn’t an
Entity Framework blog, so I’ll leave that process to better minds than
mine. Just know that you have to deal with this aspect when using the
ASP.NET backend.
On the next page, https://shellmonger.com/2016/05/11/30-days-of-zumo-v2-azure-mobile-apps-day-19-asp-net-table-controllers/
The demonstration was using SQL syntax to create/manage the Azure SQL Database, such as: CREATE TABLE... and CREATE TRIGGER... and etc.
So, my question is, with either SQL(like the blog sample shown) or Entity Framework:1) Are they both able to do the exact same stuff?2) Should I only choose one of those methods only?
All the methods discussed (code first, model first, database first) provide you with a way to create a SQL database and update the data within it. The end result is the same - a database with data.
The method you pick tends to rely on where you prefer the 'intelligence' for your data to live - with the database or with the code.
Do you already have an existing database you'll be using?
Go database first, so you can automatically generate code and classes from the database.
Do you know SQL? Do you prefer to use your database for data only (i.e. no stored procedures or validating data inside the database)?
Go code first, you have full control of your model from the Code, and its a bit easier to keep databases in sync with your application.
There are a few more considerations that can help skew you to a different method. You can take a look at this blog post from Roland about the pros and cons of each approach.
There's also a StackOverflow thread that summarizes the differences between the methods.