View with Aggregation

Events happening in the community are now at Drupal community events on www.drupal.org.
ijhana's picture

I am trying to create a Report using views. The report shows the images that have been flagged by the currently logged in user. This works. Now I want to add a column for the number of times each image has been clicked on.

We created a content type that tracks the user, the image and the time of each click. 1 click = 1 node.

How do I add an aggregation that sums this total of clicks per image.

Comments

Technical discussion

Tony-Mac's picture

I don't know the answer to this question but I just wanted to posit that I welcome a technical discussion on this channel rather than countless emails about logistics.

Flag module

ejanus's picture

Are you using the Flag module? You're saying you add a node to represent every single click? How much traffic and how fast is your server? That sounds like an expensive (process wise) solution!

Flag module will undoubtedly

fejn's picture

Flag module will undoubtedly do some of the work for you, but you might want to investigate one of the Voting (http://drupal.org/project/votingapi) modules to keep track of all your information. I'm sure your method will work, but it sounds more painful than need be.

Absolutely!

ejanus's picture

I fully agree that both these modules could provide the out-of-box, supported functionality you are trying to do with your custom approach!

Computed field

fejn's picture

Investigate the use of a Computed Field (http://drupal.org/node/126522) for your app. I assume you are using D7, in which case the whole process should be much easier (no need for an extra module)

Look at the aggregation framework

btmash's picture

Its been a while since I dealt with it, but views 3.x does have an aggregation framework so you could group content by certain IDs (which is likely what you'll need to do). Look at http://nodeone.se/en/the-aggregation-setting-the-emmajane-episode

Also agree with @ejanus, the node per click is excessive.

And what emails about logistics are you referring to, @Antek?

Forgive Antek

pcher1bw's picture

Please forgive Antek, he was bombarded by Downtown LA Drupal messages all weekend, and was just voicing his pleasure at a real Drupal question here.

Paul Chernick
CEO
Chernick Consulting
(310) 569-2517

Thanks for the clarification

btmash's picture

I was a bit confused about what happened.

I mentioned the views aggregation in the event the OP wasn't in a position to change any of the rest of the architecture. To note, I just tried out the aggregation framework that is part of Views and it is fairly easy (once you enable aggregation, you get aggregation settings for each field like grouping column, count, etc). The actual resulting view should be relatively fast depending on how much data you are joining. But your site will take a hit for storing your tracking as a node (I have no idea how the relationship was set up so just stabbing in the dark here but a number of tables get touched when you save/update nodes).

I completely forgot about computed field - that is a great suggestion. Again depends on how the original tracking data is getting stored (and that is where I would see the biggest hit) but computed field would be a way to aggregate that data only when new tracking data is stored so there is less data to filter and no need for aggregating every single time when viewing a report.

Flag/VotingAPI are good as well (votingapi moreso since it actually has a cache table where it will store the tallied results like total 'votes' (your count) and so it should be even faster).