Store in sqlite parameters used to rest so we can query from db about brick

[tshedor]

Hey @porfirioribeiro good to hear from you again. I’m typing on a tiny keyboard so please excuse the formatting.

I think what would be best here are using non-final fields:

static Future<List<T extends YourBaseModel>> fetchAndAssignFromParentId(String parentId) async {
  final results = await repository.get<T>(
    query: Query(where: [Where.exact('parentId', parentId)]),
  );
  return results.map((r) => r..parentId = parentId);
}

This way, you could declare parentId in the superclass that Entity would extend. This is how primaryKey is accessible and saved on every SqliteModel.

Alternatively, because I have a feeling this may not be exactly what you’re after, there’s an afterSave hook for SqliteModels (OfflineFirstWithRestModel is a SqliteModel subclass) that may have access to query. I’m...not sure. I’ll get back with you when I’m not on this tiny keyboard.

[porfirioribeiro]

Thanks for your quick answer @tshedor

I found a way to make it work by passing seedOnly, without it i would always get 0 results, and then store it again on sqlite after setting the parentId.

Future<List<Entity>> getEntity(
    MyRepository repository, String parentId) async {
  final entities = await repository.get<Entity>(
    alwaysHydrate: true,
    seedOnly: true,
    query: Query(where: [Where.exact('parentId', parentId)]),
  );

  await Future.wait(entities.map((e) => repository.sqliteProvider.upsert(e..parentId = parentId)));

  return entities;
}

It works, but it's a bummer that i have to store it again on Sqlite right after getting it and saving it.
What i was trying to achieve was be able to do something between the data came from Rest and be stored in Sqlite.

For what i could see, afterSave has no access to the query, and even if it did, it's called after saving to Sqlite, so would be the same.

Maybe would be possible to add a beforeSave that would receive the query and be able to manipulate the instance before storing on Sqlite?

[tshedor]

@porfirioribeiro You're right, there aren't arguments for query on the Save hooks. Sorry, I steered you in the wrong direction there.

I have some concerns about including query from an architectural view:

• The query should only interact with the provider/repository and should be resolved before data is transmitted to a provider. For this reason, a model should only be aware of data and instances, not provider config.
• REST should not interact with SQLite, as these are two independent providers and need to be modular to allow mixing by the repository. The repository's purpose is to combine providers.
• The brick domain can get/is very complex, and to maintain sanity I try to keep concerns as separated as possible (i.e. provider-repository-model).

I'd love your input if you want to push back on either of those points as you've been using this for several months and have a use case that my team hasn't yet come across.

Now that I'm back on a big keyboard, I looked through the repository and remembered this less-documented method (it's only used by adapters). It might suit you:

class MyRepository extends OfflineFirstWithRestRepository {
  @override
  Future<List<_Model>> getAssociation<_Model extends _RepositoryModel>(Query query) async {
    final results = await super.getAssociation<_Model>(query);
    if (query?.providerArgs != null) {
      final parentId = query.providerArgs['parent_id'];
      if (parentId != null) {
        return results.map((r) => r..parentId = parentId);
      }
    }

    return results;
  }

}

#getAssociation is invoked before #hydrate so if the record needs to be saved in your providers it will be later and you don't need to worry about upserting here.

[porfirioribeiro]

I think #getAssociation is only called if the model actually have any model association, which is not the case. And that function is not called. Solving this at the repository level would probably not be the best place, i don't know.

I understand the situation, managing to keep all this abstractions working together is not easy, and I'm very thankful for all the work you are putting on this. I've been able to workaround most quirks i found, and adapt this library for our app. Probably i should expose those to you, to be aware of.
We are starting to bring the App for production, and we have some customers already testing it.

It's not the first time i got this problem, but the last time i was able to fix it at the backend side by adding that field to the response, but this time was a bit more complicated.

Well, the workarounds are currently working, so we can keep it this way, and maybe later we can find a way to solve this problem in a better way!

[tshedor]

Closing because of workaround