@tsteur opened this Pull Request on November 25th 2019 Member

Otherwise it is hard to find out for what period etc the query was. Ideally we would add segmentId instead of segmentHash but would need to refactor some code from segmentQueryDecorator to the segmentClass (the method that finds the segmentId for a segment)...


SELECT /* 2019-11-25,2019-11-26 sites 1 segmenthash 6fb490cfce17323e01f4d11d61ea9679 */ /* Core */
                count(distinct log_visit.idvisitor) AS `1`, 
            count(*) AS `2`, 
            sum(log_visit.visit_total_actions) AS `3`, 
            max(log_visit.visit_total_actions) AS `4`, 
            sum(log_visit.visit_total_time) AS `5`, 
            sum(case log_visit.visit_total_actions when 1 then 1 when 0 then 1 else 0 end) AS `6`, 
            sum(case log_visit.visit_goal_converted when 1 then 1 else 0 end) AS `7`, 
            count(distinct log_visit.user_id) AS `39`
                piwik_logtmpsegmentde86627ef24972fd077a35a9eb0dc563 AS logtmpsegmentde86627ef24972fd077a35a9eb0dc563 INNER JOIN piwik_log_visit AS log_visit ON log_visit.idvisit = logtmpsegmentde86627ef24972fd077a35a9eb0dc563.idvisit 
@diosmosis commented on November 27th 2019 Member

I was looking at the code for the SegmentQueryDetector code and it seems like it should be called no matter what (since Segment::getSelectQuery() is called which calls getSelectQueryString() on the LogQueryBuilder. Is it not doing that currently?

@tsteur commented on November 27th 2019 Member

I think the segmentQueryDecorator maybe gets only called when the create temporary table select segmentquery is being executed?

@diosmosis commented on November 27th 2019 Member

I see, there's an if I didn't notice...

This Pull Request was closed on December 10th 2019
Powered by GitHub Issue Mirror