Currently, I am using react-native couchbase lite for integrating couchbase into the application. So I was facing problem in data modelling and how to use it with the Swagger API in the application.
Currently, my schema looks like this
{
“key1”:“value1”,
“key2”:“value2”,
“key3”:“value3”,
“arrayObject1”:[{
“key”:“value”,
“key”:“value”,
}],
“arrayObject2”:[{
“key”:“value”,
“key”:“value”,
}],
}
The application requires to regularly update the array objects but they are bounded. So I don’t find any reason to include them in separate docs. So how could this be accomplished in the couchbase mobile? Also, this is a web application in which I am using ottoman to define a schema and for CRUD N1QL queries are used and data needs to be in sync everywhere on the web and the mobile App.
Also, it would be great if you have an official support and docs for the react-native platform.
Maybe I am missing the question here . Since documents in Couchbase Mobile are JSON , you can essentially model it the way you have specified it above. If you know that the size of the array isn’t very large, you can include a nested array of objects in the same document.
This documentation on Data Modeling should help you.
Yeah, I have seen the docs but the main issue here is if I do the nested document then how can I update or delete the single object present in the arrayObjects defined in the schema above. I didn’t find any suitable REST API for this like how to do update subdocs.
Also when we are expecting the CBLite 2.0 to be launched for production usage.I think it might help as it has N1QL support in it?
If you are using REST API, then your option to document updates is PUT and by definition, PUTs expected to be idempotent so you will have to specify all the properties including the array property
CBL 2.0 will be going GA in a month or so. But 2.0 does not support a REST API so you will not be able to use the react native plugin.
We are internally evaluating options for React Native and Hybrid apps support post 2.0 (CC @ssmotra)
Okay, So according to you what is the best option for this?nested or separate docs? I think there might be more conflicts in the nested case?
Also, Can you give me some idea about like how to authorize users in web and mobile both? Like on the web I am using nodeJS and JWT for maintaining sessions and in mobile, we have the sync gateway for maintaining it. So I am getting a little confused in it.
Yeah, Sure I will be waiting eagerly for this and hope it comes soon so that it just ease down my process of developing in couchbase and react native
It depends on your app needs . If you always expect to access all (or most) of the members of the array at the same time then it could an overkill to have separate documents for each member of the array because you would have to do multiple queries to fetch the documents associated with each of the array members.
Now, if the the array size is large, then putting all of it in a single document would have adverse affects as well. Your document will become quite large. We just looked at one case in your question - even if you are only updating a part of the document, you will have to load entire document and write it back to disk which can incur a penalty if doc is large . Document size also has an impact on replication performance.
And yes- if you put everything in one document, likelihood of conflicts increases but if you resolve those, that shouldn’t be a concern.
So couple of questions to consider is whether you expect this array to become very large and if you need access to all members of the array at same time.
Can you raise a separate ticket for this please since its unrelated to the original question .
Basically, there are different screens for different array objects. So I think keeping them in separate docs is a better solution. But the problem here comes in when we are using the web app and updating docs on the Couchbase Server. They are all done in a single nested document on the web and with help of N1QL we can easily update the sub docs. Hence , I am somewhat stuck in between to model the data properly.
The thing to consider now is that since you will be syncing the data over to the mobile clients , you have to be cognizant of the document size . There are network considerations as well.
These considerations are unique to mobile .
Are the documents segregated by user ? Then you can be filter what you want to replicate and chances of conflicts are probably not that high.
Sorry, I didn’t get your point. As the web app has a single nested document so how would I able to show that respective doc in the mobile as we have modeled the data in separate documents. Do I need to change the data model in web app too or Is there any workaround??
I think we have already gone over the trade offs of nested versus doing separate documents and we have established that for your mobile app, it would probably make more sense to not nest everything.
That said , I was trying to understand the data model on your server side . I understand that it’s nested but rather than just changing your entire data model, I was seeing if there is a middle ground .
Since document size is something you will have to consider with mobile in play, I wanted to determine if the document size would still be “reasonable” with the nested model .
So questions for consideration -
Do you have a single nested document for all users of your system or if you have a separate document for each user?
If you have one giant document for all users, then we should probably revisit the data model on server side. If the document is separated by user, then how big do you estimate the document to get ?
Reason being you could assign the document to separate user channels and use appropriate “filters” to replicate only documents that are relevant to the mobile user.
If this is still unclear, take a look at the filter criteria in the CBL REST POST _replicate API and see if you can segregate your documents in a way that you can apply relevant filters to pull only whats required.
Note that I just threw out “user” as a criteria because I am not familiar with your app. Point being - you could think of other criteria to segregate your data to reduce the size of document and number of documents pulled by each mobile client.