jaguar_orm
jaguar_orm copied to clipboard
Jaguar-dart
Immutability support relations
If model are immutable, all generated code about relations doesn't compile anymore.
Mostly because if generate stuff like this:
void associateCart(CartItem child, Cart parent) {
child.cartId = parent.id;
}
Future<Cart> preload(Cart model, {bool cascade: false}) async {
model.items = await cartItemBean.findByCart(model.id,
preload: cascade, cascade: cascade);
return model;
}
Future<List<Cart>> preloadAll(List<Cart> models,
{bool cascade: false}) async {
models.forEach((Cart model) => model.items ??= []);
await OneToXHelper.preloadAll<Cart, CartItem>(
models,
(Cart model) => [model.id],
cartItemBean.findByCartList,
(CartItem model) => [model.cartId],
(Cart model, CartItem child) => model.items.add(child),
cascade: cascade);
return models;
}
as models are immutable it's not possible to access setters directly
Jaguar supports immutable fields. Not immutable models. One can have immutable models if there are no relations.
If there are relations, we have to set fields to associate them.
If we come up with a method to achieve this, we can implement it.
Yes immutable fields are supported since a long time, I already use them. But what I'm interested in is immutable models :)
There is a simple way to achieve this by just returning a full copy of object with the relations instead of settings fields. That's how the all flutter frameworks works, you have a copy method you can call with the possibility to override any fields, that method return a new immutable version of the object.
What do you think about that ?
I think in general immutable models are awesome. But I do not agree with making the api and generation complex to get complete immutability. I have never used build_value and its shebang.
Please present a fully implemented, hand written bean example for one-to-one scenario with immutable relations. If it is does not complicate things, let us absorb it into the generator.
What say?
I don't think we need build_value (never used it too ^^), we just need to generate a copy method on our generator, and change the preload methods to return a new object.
I'll create a one-to-one example ASAP ! I'm reopening the issue for now, if we finally don't do it we'll close it again. But I really think we can do it without to much trouble
Here is my manual implementation of one-to-one association with immutability, all modifications can be done under the generator I think:
https://gist.github.com/jaumard/5e777dbd1f2090a7d859061aa2165f5d
Tested on my Mac with PostgreSQL DB
Let me know what you think @tejainece !
I have not got a clean proposal that does not sacrifice user friendliness for immutability.
Did you check my gist ? It doesn't sacrifice anything, just give you immutability
The approach you suggested only supports immutable models. It does not support mutable models.
I think we should handle immutable models and mutable models differently.
In fact it does, if you don't put your fields as final they are mutable for the users. What the generated code use is not really a concern imho. Also supporting mutable models it's supporting a bad practice... So not sure it worth supporting both differently (more work, less easy for users and more error prone)
If you really want to support both we can keep the current way, add a boolean field on the Bean annotation and do the immutable way if that flag is true (I would push for immutable by default but if you don't want it's fine for me ^^)