On Thu, Jul 31, 2014 at 3:44 PM, Sebastien Blanc <scm.blanc@gmail.com> wrote:



On Thu, Jul 31, 2014 at 3:17 PM, Matthias Wessendorf <matzew@apache.org> wrote:



On Thu, Jul 31, 2014 at 2:52 PM, Sebastien Blanc <scm.blanc@gmail.com> wrote:



On Thu, Jul 31, 2014 at 2:45 PM, Matthias Wessendorf <matzew@apache.org> wrote:



On Thu, Jul 31, 2014 at 2:18 PM, Sebastien Blanc <scm.blanc@gmail.com> wrote:



On Thu, Jul 31, 2014 at 12:12 PM, Matthias Wessendorf <matzew@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 

I don't mind renaming !



 

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)

ah, cool; Yeah - I've zero concerns in chaning the label :-) 

 


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 

Ok. So you don't like the "show the most (three) recent variants (and their # of receivers) " ? :-) 
Yeah why not :) , we just have to choose something that will be a real useful information, I would like from the rest of the team.

yes, I'd be interested in hearing from others as well

 
Then, if we go for this I need some clarification : 
- most recent variants, you mean most recent "active" variant, meaning the most recent that sent out a Push Message ?

yep

 
Because if you meant on Variant creation date, we don't have this info :)
- Number of receivers, sorry to ask again, I know you make the distinction with installations, but you mean the number of active tokens (i.e : we have 20 "active" (not toggled off) tokens, or the  total of receivers for all the sent messages (i.e : Message A was sent to 10 receivers, Message B was sent to 5 receivers, we show 15 ) ? 

I'd expect a 5 here (or a 15) :) - not sure 


-M

 




 
* 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@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@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@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@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@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@gmail.com> wrote:


On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius <daniel.bevenius@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@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 : 


I have change this test case : 

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



_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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