Our current model is
1 [PushMessageInformation|https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/PushMessageInformation.java] -> n [VariantMetricInformation's|https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/VariantMetricInformation.java]
during the process of processing the metrics and the notifications, we have code that locks the PushMessageInformation, in order to update it's VariantMetricInformation.
Per each variant of a PushApplication, there is exactly one.
But push notification is done in batches, so large push jobs have multiple times to update (and lock/select_for_update) the same VariantMetricInformation.
Our new data model should:
* reflect a more flat nature, represented by the UI.
* Should be stored to DB as "Processed" (enum) and only be updated to fail, when there is actually a failure.
I think we may perhaps introduce a new JPA entity, to avoid DB migrations, that has a more flat nature
|
|
