This question already has answers here:
Firebase Android - Only need specific table to be in local device
(1 answer)
How to limit Firebase database persistence store to only some nodes?
(1 answer)
Closed 2 years ago.
I'm working on a project where I'm using Firebase realtime database as my database. Most of my information will be online, but I want to keep some folders offline. As the documentation says, if I write
FirebaseDatabase.getInstance().setPersistenceEnabled(true)
Any data that I sync from database will be cached, but that's not the behaviour that I want.
Let's say that I have an app where user can create a lists with games
I have 2 folders on my DB root: games and userLists.
In my app I get all games from "games" folder, let the user choose some of them and save under:
userLists/(userId)/(listName).
If I "setPersistenceEnable" as true, all data sync will be kept offline, including games from "game" folder.
I want to keep only the folders under userLists/(userId)/ offline.
Is there anyway to achieve this behaviour?
It's not possible using a simple configuration. Using the provided API in the default setup, you can either choose to persist any of the data that you get from queries, or you choose not to persist anything at all.
If you need to persist only certain data, you will have to either:
Disable persistence, and arrange to persist only certain data on your own (perhaps in a sqlite database)
Enable persistence, but only use it for certain queries. Other queries can go through a different instance of a FirebaseApp where persistence is disabled, or use the REST API directly.
Related
This question already has answers here:
Is it safe to expose Firebase apiKey to the public?
(10 answers)
Closed 1 year ago.
In my Flutter web app, the credentials to access the Firebase backend are set in index.html and anyone who clicks "view source" can see them.
What's to stop someone from using that to spoof the client and get access to the Firestore database with their own code instead of the client that's meant to access it?
You will always have to leave a way for users to access your database - and thus also giving them some way to locate your database. You should write secure firestore security rules to govern the usage of your database. Users will always be able to access your database through other means than your front end. After all, your front end is just a portal for displaying the data in a user-friendly way. By however adding security rules you can limit the usage of your database to how it is intended.
I have seen a firebase api in which you can create firebase projects and it occurred to me for example, when a user wants to counter a SaaS, make it easier for me to create a project and connect it to their SaaS but I have the following questions:
If there are supposed to be limits to creating firebase projects in a google account, will there be a time when databases can no longer be created for new users?
If the above is true, how can this be solved?
I have seen that you can ask for more projects, but how many can I have?
I know that with firestore, I can model data and only in a database have all the information, but for example, each user may have special requirements in their system and also provide security and information saving operations that would be impossible if all information is in a single database.
Thanks for the help.
EDIT
"How many projects can you have as a developer?" Yes, that's what I mean, having all the user bases in a single firebase google account. For example, on a web page, the user wants to pay for the application, with firebase admin and google cloud functions, I can automatically create a project and have all the databases in a google account. And what I want to know is if you can have multiple databases. I have seen that you can ask google to give you permission to host several projects but, for example, can you have more than 100 projects or even 1000? (I may never have reached that number, but in that case, I would like to know the limits that can be reached).
Edit 2
This first structure I have all the documents in a "universal" collection and I identify them with an id to know the user who used it.
But the second structure seems to me more organized and clean, in addition to the fact that users at no time need to share information among others. I have read that having nested collections is not good but over the years and the progress that firestore has had, this is no longer or was a problem only that the limitation is that you can only have up to 100 collections anidades but I never think to reach that quantity.
Inside of list, have all products for that user, because inside of document, only can have 1 mb of data and download 1 mb and is not the best option.
in the firestore documentation I see that it does not reveal other problems, it only says that it is difficult to delete the subcollection, but I do not allow users to do that and if I need to delete the subcollections, with the Google Cloud functions i can do it.
So, the second structure is more intuitive for me, but is the best option for that? or actually firestore is not good for this strcucutre?
As part of a 'pet project' Flutter app that I am trying to build (in Android Studio) I am looking to add a database of information (possibly with Firebase) for users to use with the app.
My current understanding/capabilities
At the moment, I understand how to (and have already) build a database in Cloud Firestore, where the users can store their own data. A good example of this would be a to-do list app, where the user can create a new item, which is stored in the database with their uid. This remains there until they delete it manually. They are also able to update the entry, such as change the name of the item, themselves in the app.
The aim
I've got a set of data at the moment, which is in Excel format, that has the potential to have up to 1000s of rows. I would like to be able to incorporate this into my app, such that the user is able to query the database, either via multiple dependent drop-down menus, or a search widget.
My question
Is there an easy way to convert a reasonably large set of data, currently in Excel format, into a firebase-type database (such as cloud firestore or realtime database) without having to manually enter all of the data?
For RTDB, you can use use some Excel-to-JSON tool and import that JSON into RTDB. However, I doubt that the exported format will be efficient to use in your app, so you might have to do some transformations (in your language of choice).
If your data is very large (1000s of rows, but... how many columns?), you might have to split your import into multiple smaller imports at different paths of your database.
Doing huge RTDB imports in Firebase console has caused my projects to "misbehave" for a little while, but it goes back to normal quickly, so don't freak out if that happens to you too.
For Firestore, which has no direct JSON import AFAIK, take a look at How to import CSV or JSON to firebase cloud firestore for some ideas.
I am using Firebase in an app which we deployed a couple of months ago. Of course, a few database changes happened and a lot of new triggers were created, which we now want to deploy to production together with a new app version.
The question is how do we force the previous app version to work with the new triggers and database structure without forcing our users to update the old app? Does anyone have any experience or suggestions in implementing this smoothly?
Some examples of what did change:
A counter to keep track of like counts was set in the app code in the previous version. This now has been moved to a cloud function.
A collection named '/users' is now split in two collections '/users' and '/_users', with '/users' containing all data accessible for all users and '/_users' containing all data only accessible for admins. Also a trigger is built to keep corresponding fields synchronized (fe. the field firstName occurs in '/users' and '/_users') So when a new user is created in the previous app version, the document will contain too many fields, because some belong to the '/_users' collection now. How can this be handled?
I've found out that with remote config we'll be able to force the users to update the app, but still that ain't the way to go for us. The first scenario seems easy to counter by just recalculating the count in the trigger. The second seems a little more complex.
I'm planning a web application that requires user auth, plus the ability to display data for the users that is stored in a database. No interaction between the users is needed (yet), however the users should be able create objects and query their "own" objects. For example I list 10 book names (10 book objects), and User A should be able to pick a book and create a new object, call it userNoteObject that contains the name of a choosen book and a short note (that he/she writes).
With a basic pseudo code one book object would look like this:
bookObj = {"id": 1, "name": "book name"}
And the user's note object would be something like this:
userNoteObject = {
"id": 1,
"book_name": "random book name",
"owner_userid": "a1b2c3d",
"note": "some random string"
}
With MySQL I would create three tables, one for the users and one for the userNoteObject-s and another for the bookObj-s. Everytime an user saves a note, I would add it to the table that lists the saved notes. Then I can simply query the notes that belongs to X user based on the user's owner_userid. It's a quite simple functionality.
After reading about the possibilities I've made a decision to go with Firebase Auth (because in the future I might need Android and iOS compatibility) + Google Cloud Datastore or Firebase Realtime Database. However I'm a little bit scared about the Realtime Database of Firebase since I've never worked any DB like it. I also like to be able to modify records manually with something like PhpMyAdmin and I assume Cloud Datastore has a visual interface like that.
I'm familiar with JSON handling and creating JSON files, however the JSON based database is strange for me at the moment. Therefore I'm thinking about that maybe the other option would be a better choice. It's very important that I don't need realtime db features. I would load X number of entries into the table that holds the bookObj-s and sometimes update them. I assume when the user creates an userNoteObject it would be saved quickly with both and after deleting an userNoteObject I could refresh the page close to realtime with Datastore. But the table that holds the book objects must be able to store millions of entries easily.
So the important things:
One db table should be able to handle millions of records easily
Easy as possible querying
Visual interface for the DB (if it's possible)
I don't need realtime features like dynamic game score display/saving
Other info:
I would like to use Angular.js
I'm familiar with Python if it can help in something
So my question is that which database would be better for my needs? At the moment I say Datastore, but I'm totally new with these services so I'm not really against the Realtime Database, but Datastore looks more suitable since it has a visual interface. However I'm also not sure that how would work Datastore with Firebase. If there is a third option like combining both, Realtime Database for the objects save by the user and the static objects for Datastore for example, I would love to hear about it too. My overall goal is to be able to write and query the db easy and fast as it's possible and easily use it with Firebase auth.
UPDATE: I just discovered Firebase's Cloud Firestore, so if it can be more useful I could use it.
If you are going to use Firebase I would recommend you use Cloud Firestore instead of either Cloud Datastore or Firebase realtime database. You get the benefits of a real-time database plus a true document based JSON data store. The one downside is that you don`t have a UI to interact with the data. Datastore has one but its not as robust as say PHPMyAdmin. And since these are NoSQL datastores SQL support is pretty limited.
If you really want a true relational back-end you could try Cloud SQL which is basically MySQL running on Google Servers.
For the Firestore console/UI, see https://firebase.google.com/docs/firestore/using-console. Is that the kind of thing you're looking for?