Persists the targets acquired by the TargetManager
Issue by marcoguerri
Thursday Feb 06, 2020 at 15:06 GMT
Originally opened as https://github.com/facebookincubator/contest/issues/34
Right now there is no source of truth that tells which targets were acquired at the beginning of the job, that can be references for example at events submission time. To have a normalized data model, we need to store targets acquired as well.
Comment by xaionaro
Monday Mar 02, 2020 at 12:53 GMT
Am I understand correctly that the task is effectively to implement targets-lock-reentrance for a job?
Comment by marcoguerri
Tuesday Mar 03, 2020 at 05:54 GMT
This was not meant to be about target locking, but basically storing permanently all the information of targets that we acquire. The target locks backed by MySQL are meant to be ephemeral.
The idea here is instead that we need to have a way to normalize the schema when referencing targets. Right now test events for example are not normalized and it should really be fixed...
We would have a surrogate key in a targets table (target_id, although, this name becomes overloaded and we might think of something else instead) and in test events we'd reference that key.
Comment by marcoguerri
Tuesday Mar 03, 2020 at 05:56 GMT
I wouldn't merge the concepts of targets and target_locks in a single table for example because we need to keep locking independent of the storage backend.
Comment by xaionaro
Tuesday Mar 03, 2020 at 10:09 GMT
I wouldn't merge the concepts of targets and target_locks in a single table for example because we need to keep locking independent of the storage backend.
Sure, I wasn't implying it :)
Right now test events for example are not normalized and it should really be fixed...
Makes sense. OK.