I'm trying to flatten the data in my firebase app. The database design has a list of users and a list of projects. The users will own the projects and need to have a list of indexes into which projects they own. The users list is indexed by uid which is unique. With the projects I am using a list of projects with a unique ids. The projects are managed using firebaseArray and created with the $add. I'm trying to use the flattened data model illustrated in the guide in the structuring data section. The problem is that the unique ids generated by the $add have special characters in them and can't be used as the index for the project in the users object. An error is generated when trying to create an object where one of the members has 'special characters' in it.
What is the recommended way to work around this?
For my app I used the orderBy and equalTo with the userId in the projects. This seems to work very well. OrderBy seems like an odd term to use. Its more like a select.
I'm coding a little model layer on top of angularfire, it basically handles (most of ) the pain coming with denormalized data model, you may want to take a look at it angularfire-resource
PS : I'm still working on it so it's a bit early to use it in production, but i start to be pretty happy about it and it may give you some ideas
Related
I am working on small app the allows users to browse items based on various filters they select in the view.
After looking though, the firebase documentation I realised that the sort of compound query that I'm trying to create is not possible since Firestore only supports a single "IN" operator per query. To get around this the docs says to use multiple separate queries and then merge the results on the client side.
https://firebase.google.com/docs/firestore/query-data/queries#query_limitations
Cloud Firestore provides limited support for logical OR queries. The in, and array-contains-any operators support a logical OR of up to 10 equality (==) or array-contains conditions on a single field. For other cases, create a separate query for each OR condition and merge the query results in your app.
I can see how this would work normally but what if I only wanted to show the user ten results per page. How would I implement pagination into this since I don't want to be sending lots of results back to the user each time?
My first thought would be to paginate each separate query and then merge them but then if I'm only getting a small sample back from the db I'm not sure how I would compare and merge them with the other queries on the client side.
Any help would be much appreciated since I'm hoping I don't have to move away from firestore and start over in an SQL db.
Say you want to show 10 results on a page. You will need to get 10 results for each of the subqueries, and then merge the results client-side. You will be overreading quite a bit of data, but that's unfortunately unavoidable in such an implementation.
The (preferred) alternative is usually to find a data model that allows you to implement the use-case with a single query. It is impossible to say generically how to do that, but it typically involves adding a field for the OR condition.
Say you want to get all results where either "fieldA" is "Red" or "fieldB" is "Blue". By adding a field "fieldA_is_Red_or_fieldB_is_Blue", you could then perform a single query on that field. This may seem horribly contrived in this example, but in many use-cases it is more reasonable and may be a good way to implement your OR use-case with a single query.
You could just create a complex where
Take a look at the where property in https://www.npmjs.com/package/firebase-firestore-helper
Disclaimer: I am the creator of this library. It helps to manipulate objects in Firebase Firestore (and adds Cache)
Enjoy!
I have a simple question. I am building a Instagram clone app and I want to show each user to their friends. Also they can see the friends list. I am using cloud firestore approach. However I'm a little bit confused about how to store user's friends data? . Should I create a new collection as friendsList
or should I hold the data in users collection as a friends array ?
In the first approach I will create the user data again when some user adds a new friend. Am a new for both firestore and NoSql I would be thankful If anyone can explain.
I'm not going to "answer" as such, but explain the philosophy of NoSQL a bit. The best approach is to design your queries first (i.e. what do you want to get from the database), then design your database schema to make getting the results of those queries efficient and affordable. There are many ways to organize data; you want to take advantage of NoSQL "schema-less" to make your schema match your needs, not the other way around.
Other things to keep in mind: DRY is less critical to NoSQL. Static data (i.e. never or rarely changes) can be stored in multiple places (i.e. a friend's name might be in their profile and in a friends-list) if that saves reads & writes (which are the biggest factor in costs).
So how to organize your database? I don't know; what do you want your database to do?
I should read to this tutorial.This tutorial about is MySql but not important for me if you understand this tutorial you can apply firebase.
I leave a tip below.
This is mobile app which can have different kind of users. I'm using realm only for the offline storage. Say I have two users A and B and a have a List Class. This class wont ever be shared, so different data for each user. How would i go in designing the schema? Considering versioning and migration.
A. Add a primary key for the List and assign it differently to user A and B.
B. Use two different realms
There is no one good way of defining your Realm schema and the solution to choose completely depends on the exact scenario.
If you want your users data to be completely independent of each other and you will never need to use a single query to retrieve both users data or to access some common data, then using separate Realm instances for each use seems like a good approach. It provides complete separation between your users data.
However, if your users might have some shared data or if you might end up making some statistics about all of your users even though their data is independent, using a single Realm instance is the way to go. In this case you should just create a one-to-many relationship between each of your users and whatever objects you want to store in your lists like this:
class User:Object {
let stuff = List<Stuff>()
}
I'm really new to firebase, want to try out a simple mix-client app on it - android, js. I have a users table and a tasks table. The very first question that comes to my mind is, how to store them (and thus how the url to be)? For example, based on the tasks table, should I use:
/tasks/{userid}/task1, /tasks/{userid}/task2, ...
Or
/{userid}/tasks/task1, /{userid}/tasks/task2, ...
The next question, based on the answer to the first one - why to use any of the versions?
In my opinion, the first version is good because domains are separated.
The second approach is good because data is stored per-user which may make some of the operations easier.
Any ideas/suggestions?
Update: For the current case, let's say there are following features:
show list of tasks for each user
add new task to the list
edit/delete a task by user.
Simple operations.
This answer might come in late, but here's how I feel about the question after a year's experience with Firebase.
For your very first question, it totally depends on which data your application will mostly read and how and in which order ( kind of like sorting ) you expect to read the data.
your first proposal of data structure, that is "/tasks/{userid}/task1", "taks/{userid}/task2"... is good if the application will oftentimes read the tasks as per users with an added advantage of possibly sorting the data by any task's "attribute" if I might call it so.
say each task has got a priority attribute then,
// get all of a user's tasks with a priority of 25.
var userTasksRef = firebase.database().ref("tasks/${auth.uid}");
userTasksRef.orderByChild("priority").equalTo(25).on(
"desired_event",
(snapshot) => {
//do something important here.
});
2. I'll highly advice against the second approach because generally most if not all of the data that is associated to that user will be stored under the "/{userid}/" node and with firebase's mechanism, should a situation be in which you need more than one datum at that path level, it will require you getting that data with all the other data that's associated to that user's node ( tasks and any other data included). I won't want that behavior on my database. Nonetheless, this approach still permits you to store the tasks as per the users or making multiple RESTfull requesting and collecting the required data datum after datum. Suggest fanning out the data structure if this situation is encountered. Totally valid data structure if there don't exist a use case in the application where in datum at the first level of the path is needed and only that datum is needed but rather the block of data available at that path level with all the data at the deriving paths at that level( that is 2nd 3rd ... levels).
As per the use cases you've described, and if the database structure you've given is exhaustive of your database structure, I'll say it isn't enough to cover your use cases.
Suggest reading the docs here. Great and exhaustive documentation of their's.
As a pick, the first approach is a better approach to modelling this data use case in NoSQL and more accurately Firebase's NoSQL database.
I need some help thinking about the design for my business objects.
Our database records the daily entry and exit times for the comings and goings of the employees in our company. Each record also stores the UserID of the employee, the ID of the work station the employee signed in at and obviously the date.
A user can have many Entry and Exit times at any number of work stations at any given date.
The record looks something like this:
SignInID | UserID | WorkStationID | DateTimeEntry | DateTimeExit
I have a reportviewer on my asp.net form that must display reports of this entry and exit data grouped by date, work station or user.
For example it must display all data for a specific date (and within that, ordered by work station).
Or it must display all data for a given work station (and within that, ordered by date) and other similar formats.
Until now I had a monstrosity of a method where I selected the data and constructed some kind of makeshift datatable to display on my form.
I now want to redesign using objects, but I don't know how to design the hierarchy i.e. what object contains the collection of entry and exit times, and how to I make it flexible enough that I can query it (using Linq, perhaps?) based on the various display criteria?
I'm really interested in learning more about designing objects and using the correct terminology for what I'm trying to do, so if you can point me to some articles explaining these concepts it would be very helpful too.
EDIT: Okay, at least I've learned something new. What I'm trying to do is ORM - Object-relational mapping - and .NET has an inbuilt ORM tool called Entity Framework. So far so good. Now I have to see whether it can help me figure out how to organize my data.
Well, I actually have to thank the community for not answering my question, because I got to learn a lot about Entity Framework, Linq (and its limitations with Entity Framework in .NET 3.5) and a whole bunch of other things to answer my own question.
What I ended up doing was create an Entity Model of my Database using Entity Framework and thus created the Business Objects I needed to organize my data. I learned that my data isn't designed in a hierarchy, rather there are associations such as Workstation and User that each time entry records contains. I used a Linq-to-Entities query to select the data I wanted and flattened it out using its associations (example Time.Workstation.Name or Time.User.FullName) so that in the end, my projected object contained all the data I wanted in each row of my report. My projected object was actually a POCO I created for the purpose of holding the queried data and making it available as a datasource for my rdlc report.
Finally I bound the results of my query to a Reportviewer's ObjectDataSource which connects to the rdlc file that I was able to define to my liking: i.e. Either displaying the Workstation first or the User, or whatever associated information I wanted to display.