List<ModelType>.load() doesn't fetch/load any results from the backend.

[rodrigoelp]

Trying to fetch child data of a parent record via List<M> doesn't seem to work at all (or Amplify.DataStore is not really synchronising data down)

Set Up

Given the following schema:

type Blog @model {
  id: ID!
  name: String!
  posts: [Post]! @connection(name: "BlogsPosts")
}

type Post @model {
  id: ID!
  title: String!
  content: String
  belongsTo: Blog! @connection(name: "BlogsPosts")
}

As expected, this will generate two models out of which Blog will contain a definition posts: List<Post> (for this particular scenario).

If I call my Blog instance and attempt to load data for my posts

// Imagine I fetched this instance via Amplify.API because the DataStore doesn't work right now

blog.posts
    .loadAsPublisher()
    .sink(receivedCompletion: { _ in return },
             receivedValue: { items in String(describing: items) } // this is called with empty []
    ).store(in: &disposeBag)

Reading the documentation of load it says Trigger DataStore query to initialize the collection. This function always fetches data from the DataStore.query..

Has this functionality been tested? Have I just misconfigured the project?

[lawmicha]

Hi @rodrigoelp, thanks for reporting this issue. Can you try again with the latest version of Amplify and Amplify CLI?

• I was able to successfully get this working with Amplify 1.0.4 and Amplify CLI 4.22.0.
• In the graphQL schema, having a required array of Posts actually has no effect on the provisioned backend, nor codegenerated models:

type Blog @model {
  id: ID!
  name: String!
  posts: [Post]! @connection(name: "BlogsPosts")
}

can be changed to

type Blog @model {
  id: ID!
  name: String!
  posts: [Post] @connection(name: "BlogsPosts")
}

The reason is the backend will still be provisioned with an optional array of posts on the blog and the Blog model will also reference the posts as a hasMany optional relationship. Removing the ! on [Post] seems to reflect the schema more accurately since creating a blog should not require a post.

• Saving data: A blog can be created with no posts, and then a post can be created with the blog instance. Save the blog and then save the post.
• Querying data: Query for the Blog by its Id, then accessing the resulting blog instance's posts will lazy load them

[rodrigoelp]

Hi @lawmicha, I would test this but I do not have access to our AWS services, we moved to pure GraphQL which didn't have some of these issues (about two months ago).

I agree with you in that a blog doesn't need to have posts to be created. In general parent data structures should follow that rule as any child data would be optional by definition.