I have a Flash applet that features a series of "stories".
Every time a story is clicked this is reported back to the backend, this updates a property named "storyClicks" on a node. Likewise every time a "read more" link is clicked in a story this is reported back, these are named "clickThrough".
The two properties are used to rank stories in the frontend (highest rank goes to the top).
My problem is that I update the properties (and output them) from Document e.g:
d = new umbraco.cms.businesslogic.web.Document(nodeId); ... d.getProperty(prop).Value = val + 1;
and:
Document c = new Document(int.Parse(Request["id"])); int.TryParse(c.getProperty("storyClicks").Value.ToString(), out clicks); ...
I am doing it on Document because I don't wan't to publish the node (if the administrator is working on it and it is suddenly published due to a visitor clicking the story).
From what I read this updating of Documents leads to a new cached document being created for every update of these properties, which potentially leads to a massive database. And accessing Document is supposed to be slow as well?
In this specific case I would like NOT to create custom tables in the database.
So my question is; Should I abandon the above mentioned approach and, if yes, how should I manage the ranking properties?
As far as I can tell, you are taking the correct approach.
From looking at the code (via Reflector) for v4.0.3 - assigning to the Value of a Property will do an UPDATE to the database ... but it doesn't do a publish (or XML cache refresh).
So unless you start seeing performance problems - depending on your traffic, there might be a lot of database reads/writes - you should be fine.
So you don't think that the procedure of updating Document references creates extra rows in the database (e.g. it is an actual update by id, not a "history" entry)?
If that's the case I'm happy :)
The read/writes would be there anyways, I just don't know enough about the "inner workings" of umbraco to determine if I'm doing some inappropiate implementation here.
The problem with this approach is (as you already mentioned): concurrency:
Editor/Admin opens a document
You update the property while someone is working on the document in the backend
Editor/Admin publishes the document they opened earlier
Result: they overwrite the new value with the old value that was fetched before the update
In this case, if it's an important counter, I'd put the count in a different table.
The other reason that I'd go directly to the database is for performance reasons, as I'm not sure what exactly happens in Umbraco when you update a property, it could trigger multiple queries. But this all depends on how busy your site is of course.
A whole different route you could take is to just implement Google Analytics, it can track events for you from a simple javascript call. That way, you offload everything onto Google.
I need to use the statistics for a ranking system, so I would have to retrieve these values from Google Analytics via some API before generating the output. And in this specific case there's already some tracking service involved that I need to send statistics to, and I'm not sure they provide an API for gathering the tracking data?
But I see your point about authors overwriting tracking data.
Neh, if it's only for statistics then you can go with GA. But if it needs to be (semi-) real time, then definately store the data locally, GA only updates their stats once a day I think! :-)
Updating node information without publish
Hi all
I have a Flash applet that features a series of "stories".
Every time a story is clicked this is reported back to the backend, this updates a property named "storyClicks" on a node. Likewise every time a "read more" link is clicked in a story this is reported back, these are named "clickThrough".
The two properties are used to rank stories in the frontend (highest rank goes to the top).
My problem is that I update the properties (and output them) from Document e.g:
d = new umbraco.cms.businesslogic.web.Document(nodeId);
...
d.getProperty(prop).Value = val + 1;
and:
Document c = new Document(int.Parse(Request["id"]));
int.TryParse(c.getProperty("storyClicks").Value.ToString(), out clicks);
...
I am doing it on Document because I don't wan't to publish the node (if the administrator is working on it and it is suddenly published due to a visitor clicking the story).
From what I read this updating of Documents leads to a new cached document being created for every update of these properties, which potentially leads to a massive database. And accessing Document is supposed to be slow as well?
In this specific case I would like NOT to create custom tables in the database.
So my question is; Should I abandon the above mentioned approach and, if yes, how should I manage the ranking properties?
Hi mt,
As far as I can tell, you are taking the correct approach.
From looking at the code (via Reflector) for v4.0.3 - assigning to the Value of a Property will do an UPDATE to the database ... but it doesn't do a publish (or XML cache refresh).
So unless you start seeing performance problems - depending on your traffic, there might be a lot of database reads/writes - you should be fine.
Cheers, Lee.
Hi Lee
So you don't think that the procedure of updating Document references creates extra rows in the database (e.g. it is an actual update by id, not a "history" entry)?
If that's the case I'm happy :)
The read/writes would be there anyways, I just don't know enough about the "inner workings" of umbraco to determine if I'm doing some inappropiate implementation here.
I believe that the audit/revision happens on publish - might need a someone (who is familiar with the core source code) to confirm that.
Guess the easiest way is to update the property and check the audit trail.
I still reckon you're taking the right approach.
Cheers, Lee.
The problem with this approach is (as you already mentioned): concurrency:
Sebastian >
I need to use the statistics for a ranking system, so I would have to retrieve these values from Google Analytics via some API before generating the output. And in this specific case there's already some tracking service involved that I need to send statistics to, and I'm not sure they provide an API for gathering the tracking data?
But I see your point about authors overwriting tracking data.
Neh, if it's only for statistics then you can go with GA. But if it needs to be (semi-) real time, then definately store the data locally, GA only updates their stats once a day I think! :-)
is working on a reply...