Is your feature request related to a problem? Please describe.
This is a continuation of issue #5050.
My solution has a mobile app and a Web/Desktop back end. I have 45 Tables/Models which means that I'd have to have 135 subscriptions. Many of the tables I have in my database do not need to go anywhere near the mobile app and are there to support back end functionality. So I need the ability to specify which tables are subscribed on the mobile/datastore environment.
If I can do that then I can easily live with the 100 susbcription limit - but taking the whole database won't work.
Describe the solution you'd like
In DataStore to be able to select which tables/models are subscribed
Describe alternatives you've considered
As described in #5050 there are no alternatives - this is a show stopper if your database is of this size.
I have been through my database and added @model(subscriptions: null) to 17 of the 45 tables. So if we could select the tables that are enabled for subscription I'd only need (45 -17) * 3 = 84 subscriptions.
Hi, @sacrampton your proposed solution is on our road map for DataStore. We'll keep this issue updated as we make progress on it.
Hi @iartemiev - thanks for getting back to me. It looks like I need to stand down any move to DataStore for the foreseeable future. This is obviously a big step for us to remove DataStore from our planning, and one that I'm reluctant to take so I'm going to ask for an explicit confirmation before I take that drastic step.
As it stands today, if your schema.graphql has more than 33 @models (tables) then there is no way that DataStore can be connected to your AppSync back end. That until this issue is addressed there is absolutely no way we can use DataStore and there is no work around that can be applied in any way/shape/form. We currently do not know if this limitation will be overcome in the short term or the long term.
Sorry to ask for this clarification explicitly, but it affects my planning so I need absolute clarity on this. If you could confirm what I stated is a correct understanding of the situation I'd appreciate it.
@iartemiev Any update on this.
@iartemiev Any update on this issue?
I first created an issue related to an offline searchable cache back in September last year (#4085) and am trying to implement DataStore to solve these issues in my production app. My mobile app doesn't need 33 @models - but my total solution (of which the mobile is a component) needs probably double this amount of models. My total solution is comprised of mobile and web components. I need to be able to select which @models my app subscribes to and that fixes the issue.
I need a solution for my app, but I seem to be running into issue after issue that are show stoppers each time. This limitation is the latest show stopper so its really critical to get an indication of when a solution (even a work around) might be available.
@sammartinez @iartemiev @manueliglesias
Are there any work arounds for this problem? Currently it would appear that if your entire AppSync schema has more than 33 models you cannot use DataStore. I'm trying to get this confirmed whether we are truly dead in the water on this, or if there is a work around.
My application has a WEB/Backend component and a MOBILE component. The TOTAL solution has 45 models at the moment, but the MOBILE component doesn't need access to all 45 models. I use under 30 models on the MOBILE component, so as long as I can select which ones that subscribe then this all works.
Is there are work around or any other solution to allow me to proceed. Offline persistent cache is critical to me. Please advise / provide guidance on this critical issue.
Hi @sacrampton
One thing you can try for now is to manually modify the schema.js file generated in your models folder to remove the models you don't care about on your mobile app.
Please note that you would have to do this every time you change the schema since the modelgen command would put them back again
@manueliglesias - WOW - THANK YOU!!!! That is a fantastic suggestion.
Would love to see some progress on this front as we're going to be running up against this in about a month with the extra models we have to implement.
we have 47 models, that are all needed and have started hitting this limit
@iartemiev @manueliglesias Just wanted to check back on this - it has been on roadmap for 6 months and remains a big issue
Most helpful comment
@iartemiev Any update on this.