Actually I'm preparing for Instant App. Consider I've the following feature modules. And each module has its own data layer with Entity and Dao classes.
->feature-base
->feature-profile
->feature-payment
->feature-dashboard
Where should I place my "RoomDatabase" class?
I want to keep all my app data in single database. I can't place my "RoomDatabase" it in base module or at each feature!
Kindly suggest the right way of using "Room Database" in Instant App feature modules.
Ran into exactly this issue yesterday. The base module is where I have my RoomDatabase class, but it requires access to my entities sitting in the feature modules.
Do we add all the entities into the base?
When the user download the instant app, the base will create the entire db with all the entities?
I'm looking for some insight into this as well.
I feel like there are three possible solutions here and each probably has their own pros and cons. Interested to hear what others come up with too.
Each feature module has a database and data layer that is exclusive to that module. The Database, DAOs, Entities, etc. are all contained within the feature module. The obviously results in a cleaner separation of modules, and integrity of data between instant apps and the full app (as there is no change in data architecture). On the other hand it may affect performance and it definitely affects the way relationships can be formed and prevents data relationships being formed between modules.
Each feature module defines its own DAOs and Entities, but databases are defined by the various app modules (e.g. 1 for installed, 1 for Feature A instant, 1 for Feature B instant, etc...). Each of these app module databases defines only the DAOs required for that version of the app (so installed will pull in all of them, but Feature A will only pull in the DAOs and Entities relevant for Feature A). The benefit of this is having a single database allowing relationships to be more easily formed. However this is also a double edged sword as depending on how dense your relationships are you may need to pull in the whole database anyway even if the feature only uses one Entity. Another potential issue is data integrity, I'm not entirely certain how it will work having multiple databases across different versions of the app. A user moving from instant to installed may end up losing data because the underlying database is different.
In this scenario you have a single database and collect all your entities and DAOs into a single data layer that is shared between all modules. This obviously isn't as ideal in code separation and means that feature A is required to include code that's only used in feature B. But it would ensure the integrity of data and wouldn't restrict entity relationships in any way.
To anyone who still has this issue, including me at the moment, I have come across this Medium article and would like to reference it here. Hope it helps a little.
Basically, the author has mentioned that he has contacted Yigit himself and that Yigit suggested to
create a new db file into each feature module and have a database per module.
Thanks for linking my blog. Yes, I contacted Yigit after opening this issue, and went ahead with multiple databases for each module. Have not run into any problems as of now.
Thanks for your input. I have a question..but let's say that all your feature modules require the same base entity to function (i.e User table), where all other tables somehow need reference to the users, what do you do? Do you create seperate a database in Base module? Or do all the databases inside all feature modules have a copy of a user table that has to be synced across? I hope you get my question.
Create a base-db module and put your entire database into it. Share that module across all feature modules
This issue isn't related to these samples. Feel free to track the feature request on the issue tracker.
Most helpful comment
I feel like there are three possible solutions here and each probably has their own pros and cons. Interested to hear what others come up with too.
Option 1 (Database per feature module):
Each feature module has a database and data layer that is exclusive to that module. The Database, DAOs, Entities, etc. are all contained within the feature module. The obviously results in a cleaner separation of modules, and integrity of data between instant apps and the full app (as there is no change in data architecture). On the other hand it may affect performance and it definitely affects the way relationships can be formed and prevents data relationships being formed between modules.
Option 2 (Database per app module):
Each feature module defines its own DAOs and Entities, but databases are defined by the various app modules (e.g. 1 for installed, 1 for Feature A instant, 1 for Feature B instant, etc...). Each of these app module databases defines only the DAOs required for that version of the app (so installed will pull in all of them, but Feature A will only pull in the DAOs and Entities relevant for Feature A). The benefit of this is having a single database allowing relationships to be more easily formed. However this is also a double edged sword as depending on how dense your relationships are you may need to pull in the whole database anyway even if the feature only uses one Entity. Another potential issue is data integrity, I'm not entirely certain how it will work having multiple databases across different versions of the app. A user moving from instant to installed may end up losing data because the underlying database is different.
Option 3 (Single Database):
In this scenario you have a single database and collect all your entities and DAOs into a single data layer that is shared between all modules. This obviously isn't as ideal in code separation and means that feature A is required to include code that's only used in feature B. But it would ensure the integrity of data and wouldn't restrict entity relationships in any way.