Best practices on managing ids about brick

[tshedor]

Hey @mrmeyers99 thanks for using Brick.

Brick does use an internal primary key, and that key should not be managed by application code. This key is also not transmitted to Rest. It's a SQLite-only key. There is one caveat on where your application code should access this primaryKey: when the instance is being copied, like in the MaterialTheme TextTheme sense:

Pizza copyWith({List<String> toppings}) {
  return Pizza(
    toppings: toppings ?? this.toppings,
  )..primaryKey = primaryKey;
}

Regarding identifying data between your API and your client, that's a little less clear since APIs vary. The API should transmit a key that identifies that data - this could be an autoincrement key from a database, or it could be a generated ID. Brick has an annotation @Sqlite(unique: true) for associating these foreign identifiers to client-side data (and adding an index to the column in your API to ensure uniqueness/quick lookups). To avoid conflicts with identifiers, I'd recommend the UUID pacakge which handles ID generation with different protocols (the differences are important and I'd recommend doing some research to fit your needs; v1 is best for many clients but v4 is more standard).

If you're still structuring your API, I'd also recommend writing endpoints that are exclusive to their domain. For example, if you want pizzas for customers, your endpoint would be /pizzas?by_customer_id=<id>. If you want customers, you use /customers and the payload includes nested pizza data (pizzas: [{}]) OR an array of IDs (pizzas: []). Brick supports both so long as the receiving endpoint is configured.

in your endpoint body, I'd also recommend accessing instance when making mutating calls:

if (query.action == QueryAction.upsert && instance != null) {
  // or return "/pizzas?by_customer_id=${instance.customer.id}"
  return "/customers/${instance.customer.id}/pizzas";
}

And you're right that documentation is missing on this. Where did you look to find this, or rather, where did you expect this documentation to live? I'd like to add it there.

[mrmeyers99]

Thanks for the suggestion. I think you're right, UUID's are probably the best bet for my use case.

As far as documentation, I think a section between Providers and Repositories and Learn that talks about the server side considerations would be nice. Also, maybe more complete server side code in the example project that shows creating a pizza would help.

[tshedor]

Resolving in #117