Yes, your point is valid, but in the latter part SubscriptionStatisticDTO subscriptionStatisticDTO = subscriptionDAO.getSubscriptionStatistic (deviceIdsOwnByGroup, isUnsubscribe, tenantId, applicationReleaseDTO.getId()); when getting the stats, we're considering the release id. So the device type constraint will be implicitly satisfied.
Yes, your point is valid, but in the latter part `SubscriptionStatisticDTO subscriptionStatisticDTO = subscriptionDAO.getSubscriptionStatistic
(deviceIdsOwnByGroup, isUnsubscribe, tenantId, applicationReleaseDTO.getId());` when getting the stats, we're considering the release id. So the device type constraint will be implicitly satisfied.
Yes, otherwise if a scenario like triggering an android application installation to group which have both the windows and android devices assigned to it then those app irrelevant devices (in this case windows) are also being counted for the device count but they are not relevant to that app installation. Here we are getting only the completed, pending and error device count and substract it from the total device count and assign that remainder to the new device count and pass it for the calculation of percentages so, when the device type of the application supported is not considered it will count all the devices relevant to that group so the new device percentage might be wrong.
Yes, otherwise if a scenario like triggering an android application installation to group which have both the windows and android devices assigned to it then those app irrelevant devices (in this case windows) are also being counted for the device count but they are not relevant to that app installation. Here we are getting only the completed, pending and error device count and substract it from the total device count and assign that remainder to the new device count and pass it for the calculation of percentages so, when the device type of the application supported is not considered it will count all the devices relevant to that group so the new device percentage might be wrong.
Please handle this with two exceptions and add two different error messages, it will be useful when we analyze logs if we get an error with this functionality.
Please handle this with two exceptions and add two different error messages, it will be useful when we analyze logs if we get an error with this functionality.
}catch(SQLExceptione){
Stringmsg="SQL error occurred while retrieving device count.";
log.error(msg,e);
thrownewGroupManagementException(msg,e);
}catch(GroupManagementDAOExceptione){
Stringmsg="DAO error occurred while retrieving device count.";
In this service method are we considering the device type of the application supported?
Yes, your point is valid, but in the latter part
SubscriptionStatisticDTO subscriptionStatisticDTO = subscriptionDAO.getSubscriptionStatistic (deviceIdsOwnByGroup, isUnsubscribe, tenantId, applicationReleaseDTO.getId());
when getting the stats, we're considering the release id. So the device type constraint will be implicitly satisfied.Yes, otherwise if a scenario like triggering an android application installation to group which have both the windows and android devices assigned to it then those app irrelevant devices (in this case windows) are also being counted for the device count but they are not relevant to that app installation. Here we are getting only the completed, pending and error device count and substract it from the total device count and assign that remainder to the new device count and pass it for the calculation of percentages so, when the device type of the application supported is not considered it will count all the devices relevant to that group so the new device percentage might be wrong.