On Thu, Jul 31, 2014 at 2:45 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
On Thu, Jul 31, 2014 at 2:18 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
>
>
>
> On Thu, Jul 31, 2014 at 12:12 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>
>> I think original idea was to show the three most busy (in number of
>> receives, not installations)
>>
> The total number or receives for one Variant , right ?
> So, if variant A "sended" a first time to 20 receivers and after that did
> a selective send 5 : the number that must showned is 25
> And we want the top 3 of this total ?
>
uhm, there was a thread in the past. Burr added something, and Hylke....
and we were somewhat talked into this (I guess we did not think too much
about it :-( )
So... I think.....
we perhaps could:
* show the most (three) recent variants (and their # of receivers)
We could do that but then we will need to change the naming
But IMO not doing a count. Perhaps that means some code needs to be
rewritten...
Well, I just managed to modify the query to really get the 3 variants
having send to the most receivers :
createQuery("select distinct vmi.variantID, SUM(vmi.receivers),
vmi.pushApplicationID from VariantMetricInformation vmi" +
" where vmi.variantID IN (select t.variantID from Variant t
where t.developer = :developer)" +
" GROUP BY vmi.variantID ORDER BY SUM(vmi.receivers) " +
DESC)
.setMaxResults(3)
.setParameter("developer", loginName)
.getResultList();
And the code don't need to be rewitten (just changing the label on the
dashboard that is now a bit confusing)
Also... "Most active" could mean something else:
* TOTAL number of receivers (per variant/app) -> like a count
Yeah that is what my query above does now
* TOTAL number of messages (per vairant/app) -> like a count on
the actual
message
I think I do (now) like the first (show the most (three) recent variants
(and their # of receivers) ) the best :-)
>
>
>>
>>
>>
>>
>> On Thu, Jul 31, 2014 at 11:42 AM, Sebastien Blanc <scm.blanc(a)gmail.com>
>> wrote:
>>
>>> BTW,
>>> I wonder how we had in mind the computing of the 3 busiest variants,
>>> what does it mean exactly ?
>>> Should we not sum up all the receiver for each VariantMetricInformation
>>> and from there get the top 3 ? Not sure this is happening right now, maybe
>>> @matzew or @edewit could give more info.
>>>
>>>
>>>
>>> On Thu, Jul 31, 2014 at 11:31 AM, Daniel Bevenius <
>>> daniel.bevenius(a)gmail.com> wrote:
>>>
>>>> Sorry, looking into this and I can't see any easy fix.
>>>> The problem as I see it is that the for the same variantId there can
>>>> be multiple receivers. But we currently don't know which
ApplicationVariant
>>>> the receivers belong to. So we cannot match them up in DashBoardService.
>>>> This my first time looking at the code so I might be missing
>>>> something. So I'd say your first post about the query being wrong is
>>>> correct, and we have to take the match the VariantMetricInformation and
>>>> match it with a pushApplicationId. Again, I could be way off here :)
>>>>
>>>>
>>>>
>>>>
>>>> On 31 July 2014 10:47, Daniel Bevenius <daniel.bevenius(a)gmail.com>
>>>> wrote:
>>>>
>>>>> Hey Seb,
>>>>>
>>>>> sure let me take a closer look at this. I'm getting the feeling
that
>>>>> it might not be as simple as that. Let me push something and we can
discuss
>>>>> it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 31 July 2014 10:39, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
>>>>>
>>>>>> Hi Dan,
>>>>>> Not sure if I understand exactly what you meant, could do a
small
>>>>>> snippet ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius <
>>>>>> daniel.bevenius(a)gmail.com> wrote:
>>>>>>
>>>>>>> Oh I see. Then I'd say you'll need to change the
return type to
>>>>>>> either use a custom object for the key in the map, or perhaps
return a list
>>>>>>> with that came custom object. What ever makes the most sense
in this use
>>>>>>> case. Makes sense?
>>>>>>>
>>>>>>>
>>>>>>> On 31 July 2014 09:39, Sebastien Blanc
<scm.blanc(a)gmail.com> wrote:
>>>>>>>
>>>>>>>> Well, several VariantMetricInformation instances can have
the same
>>>>>>>> VariantID, at each send , one is created :
>>>>>>>>
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius <
>>>>>>>> daniel.bevenius(a)gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Is this because variantFour and variantFive have the
same
>>>>>>>>> variantId (231543432434)? When added to the map only
one will exist later
>>>>>>>>> in findTopThreeBusyVariantIDs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 31 July 2014 09:20, Sebastien Blanc
<scm.blanc(a)gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Morning Peeps,
>>>>>>>>>>
>>>>>>>>>> I'm currently trying to fix AGPUSH-848[1].
>>>>>>>>>> Basically, the number of receivers shown in the
top3 list is not
>>>>>>>>>> always accurate.
>>>>>>>>>>
>>>>>>>>>> I suspect that something is wrong with this query
:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model...
>>>>>>>>>>
>>>>>>>>>> I have change this test case :
>>>>>>>>>>
>>>>>>>>>>
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model...
>>>>>>>>>>
>>>>>>>>>> By adding just one VariantInformation[2] and now
the test is
>>>>>>>>>> failing and I have no idea why, so I would
aprreciate a second eye on this.
>>>>>>>>>>
>>>>>>>>>> I'm probably missing something obvious but I
can not see it
>>>>>>>>>> right now :)
>>>>>>>>>>
>>>>>>>>>> Sebi
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [
1]https://issues.jboss.org/browse/AGPUSH-848
>>>>>>>>>> [2]
>>>>>>>>>>
https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile...
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> aerogear-dev mailing list
>>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> aerogear-dev mailing list
>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog:
http://matthiaswessendorf.wordpress.com/
>> sessions:
http://www.slideshare.net/mwessendorf
>> twitter:
http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev