Surya Asriadie

hmmm true, looks like this mostly used in unit testing in this repo, not very sure about use case outside this repo 🤔 how about, for now we can do...

ah forgot that we pass map of Mutates instead of Mutation to adapter, seems breaking change is un-avoidable 🤦 https://github.com/go-rel/rel/blob/1cac74f8a195c3e0453f62734c3fd780ef2b4228/adapter.go#L15-L17

> yes that was my proposal to change map[string]Mutate to Mutates in interfaces and expose only needed functionality with type functions and hide underlying storage structure How will Mutates looks...

any reason why not reuse existing `Mutation`? is it to avoid passing the association?

> Yes Mutation can also be reused for this. Just field Mutates needs to be made private and different type not map if not using map, how will you handle...

> I don't seem to be finding anywhere where currently there would be need to access Mutate by field name (only use case currently seems to be only to not...

basically need to shift the whole array? I don't see why that's better than map of linked list, which just changing the pointer 🤔

> copied Mutate value somewhere that would point to different next that in the original map where it could have been changed (like same deleted element). hmm, even if we...

let's go with the `slice` + `map[string]int` solution 🚀 (seems map of linked list item is not a very clean solution, a lot of pointers involved https://go.dev/play/p/tIgI5M2fWq0)

I think this work around should work: ```go repo.Insert(ctx, record, rel.NewStructset(record, false), rel.Set("created_at", nil)) ``` --- We need to analyze how many change needed if we introduce ops type to...