citizenlab icon indicating copy to clipboard operation
citizenlab copied to clipboard

CL-959

Open adessy opened this issue 2 years ago • 1 comments

Sorrry, didn't have time. Maybe later 😴

(Watch out: seems tests are not running... probably bc of the force-pushed.)

adessy avatar Aug 11 '22 07:08 adessy

Warnings
:warning: The changelog hasn't been modified
Messages
:book: Jira issue: CL-959

Generated by :no_entry_sign: dangerJS against 0c48334566fd42a418f146179596c5f2121888ae

cl-dev-bot avatar Aug 11 '22 08:08 cl-dev-bot

I'm not sure we should go with this. The code is fine, and I'm sure it works, but I think that we want to keep our data layer as clean and normalized as possible. I don't think syncing options and areas through our application layer is a good idea, it will bite us sooner rather than later. Because data manipulations will happen behind the back of our application layer, because the syncing logic will fail or records will be created that skip the AR hooks, because the application will fail with an unrelated error and not perform the syncing.

Given the effort put into this, it must be that I don't understand well enough what pain this is creating today. We have a few places where we need to deal with this exceptional behavior (using areas instead of custom field options for the field), and while it's always nicer to not have these, I don't consider this a great pain or big complexity in the code today. It's all quite contained and small in terms of code. So it must be that for representation, this is a big pain, and I'm not getting yet why.

I understand this is blocking the release of representation, so syncing today to understand how urgent it is to get this out.

kogre avatar Aug 23 '22 07:08 kogre