One-to-Many Joins has inconsistent response

[tshedor]

@tshedor I will try to summarize my issue as much as I can though I must accept that I might have skill issue regarding brick I apologize for that:

Question:

I might be experiencing some challenges regarding how Brick handles one-to-many relationships. I'll summarize the issue and my expectations to make it clear:

Context

I have two models:

• Model A
• Model B

Model B contains a list of Model A objects (List<A>), and Model A has a b_id field that acts as a foreign key referencing the id of Model B in Supabase. The database schema ensures that b_id is properly set up as a foreign key.

Expectations

When querying for an instance of Model B using Brick (e.g., repository.get<B>()), I expect the resulting object to automatically include the associated List<A>. This means that each Model B should be populated with its related Model A instances.

Observation

This expectation is not consistently met. Specifically:

• If I query Model B without any condition (e.g., repository.get<B>()), the associated List<A> is sometimes populated correctly.
• However, in other cases, especially with queries involving conditions or filters, the relationship does not seem to resolve, and the List<A> is left empty or incomplete.

Request

I would like to understand:

1. How Brick handles one-to-many relationships when querying models, particularly in the context of foreign keys.
2. Whether this behavior is expected or if there might be a misconfiguration in my models or repository setup.
3. Any recommended steps to ensure that querying Model B reliably includes the associated List<A> objects.

Originally posted by @richard457 in #528

[tshedor]

@richard457 When there isn't the same response, especially with queries, the first step of debugging is to make sure you're getting the right data from the remote. In VS Code, you can open the Dart Dev Tools Network page and watch the requests go to Supabase. Look at the Response tab to ensure that your app is receiving the data that exists in your database.

If there isn't a network call, add the policy policy: OfflineFirstGetPolicy.awaitRemote. This will require a network call. By default, Brick only fetches data when it doesn't exist locally, which may or may not be your case here.