In an intranet scenario, we might want to add the facility to comment on articles. This would make comments a child document type, which is simple enough.
But then if I want to list the most commented articles, I guess I could compute this on the fly somehow?
Alternatively, the option is to hook into the document save on the comments and update a property (commentCount) on the parent article document?
Any advice on the better solution?
Also, I can't easily find documentation on the API for v7?
I assume I would need to add and MVC code to do this to App_Code or somewhere else?
I personally wouldn't look at using a document type for comments. Instead I would consider something a bit more custom. For example a database table of comments with the document id against it.
Alternatively you could use the relationships api to associate different documents together.
The reason for not using a document type / updating a document is each time you save and publish you will be updating the Umbraco cache file which is a large XML file written to disk. If, for example, you have hundreds of comments being posted this file is being overridden every time, slowing down the operation of the site.
You could put the table in the Umbraco db, and yes something like petapoco could do the job for accessing it.
Umbraco stores all of the data in SQL, but in order to prevent lots of db requests for every page load it generates an XML cache of the content pages. This is much faster for serving pages and is updated on every publish.
When you are referring to large intranets with many documents being written what do you mean?
Umbraco, from my experience, can have alot of content published in a short space of time without an issue. One of the issues, however, with something like a property that is updated each time another document is updated is that each publish also creates a new version in the history of the document. For something like "number of comments" or "likes" this is overkill and unnecessary load on the publish mechanism.
I am thinking of an intranet with hundreds (if not thousands) of documents but only 5 or 6 comments added a day, so in total (including other document types) probably considerably less than 50 documents added a day. I am thinking the cache should be able to handle this level of activity?
Is there a way of excluding very old documents from the cache? An archive process (presumably that would mean accessing the old ones would be slow but they would be rarely opened).
And any lists I produce using Razor eg node.Children.Where".... are I assume built from SQL in real time?
ps
You said "you could put the table in the Umbraco db" - are we safe to add out own tables - nervous about this in case future Umbraco upgrades overwrite the schema or data - or do they only every update piecemeal and leave anything else alone?
I've had no issues adding my own tables to the database in the past. Plugins such as Umbraco Forms (I believe but may be wrong), use their own tables in the database and so I believe it shouldn't be an issue.
I don't think you'd have any issue with 50docs a day, I believe there are much larger sites than that running on Umbraco although none that I've made I must admit.
As far as I know there isn't any way to exclude documents from the xml cache.
With regards to your "node.Children.Where" statement, I believe this is subject to how you are getting node in the first place. If you are using something like:
@Model.Content
or
@CurrentPage
Then these will be using the cache which is the most up-to-date documents, however if you are doing the approach which is against best practice and using the content service (please don't do this!) then it might be querying the database.
If I used comments as a child document, it's simple (out of the box) but could slow the system, but maybe I should test that first and see whether it has a real impact, otherwise I need to start doing a fair amount of coding (which I would rather do when I am more familiar with Umbraco!
Most commented / most liked?
In an intranet scenario, we might want to add the facility to comment on articles. This would make comments a child document type, which is simple enough.
But then if I want to list the most commented articles, I guess I could compute this on the fly somehow? Alternatively, the option is to hook into the document save on the comments and update a property (commentCount) on the parent article document?
Any advice on the better solution?
Also, I can't easily find documentation on the API for v7?
I assume I would need to add and MVC code to do this to App_Code or somewhere else?
TIA
Hi Tim,
I personally wouldn't look at using a document type for comments. Instead I would consider something a bit more custom. For example a database table of comments with the document id against it.
Alternatively you could use the relationships api to associate different documents together.
The reason for not using a document type / updating a document is each time you save and publish you will be updating the Umbraco cache file which is a large XML file written to disk. If, for example, you have hundreds of comments being posted this file is being overridden every time, slowing down the operation of the site.
Nik
Do you mean a table outside the Umbraco db and accessed by petapoco?
Haven't looked at this. Will research!
Interesting about the XML cache - I naively assumed this was no longer there since Umbraco moved to SQL/MySQL ( hadn't really thought about this).
Doesn't this mean Umbraco is not really suitable for large intranets with many documents being written throughout the day?
You could put the table in the Umbraco db, and yes something like petapoco could do the job for accessing it.
Umbraco stores all of the data in SQL, but in order to prevent lots of db requests for every page load it generates an XML cache of the content pages. This is much faster for serving pages and is updated on every publish.
When you are referring to large intranets with many documents being written what do you mean?
Umbraco, from my experience, can have alot of content published in a short space of time without an issue. One of the issues, however, with something like a property that is updated each time another document is updated is that each publish also creates a new version in the history of the document. For something like "number of comments" or "likes" this is overkill and unnecessary load on the publish mechanism.
I am thinking of an intranet with hundreds (if not thousands) of documents but only 5 or 6 comments added a day, so in total (including other document types) probably considerably less than 50 documents added a day. I am thinking the cache should be able to handle this level of activity?
Is there a way of excluding very old documents from the cache? An archive process (presumably that would mean accessing the old ones would be slow but they would be rarely opened).
And any lists I produce using Razor eg node.Children.Where".... are I assume built from SQL in real time?
Thanks for your advice
ps You said "you could put the table in the Umbraco db" - are we safe to add out own tables - nervous about this in case future Umbraco upgrades overwrite the schema or data - or do they only every update piecemeal and leave anything else alone?
I've had no issues adding my own tables to the database in the past. Plugins such as Umbraco Forms (I believe but may be wrong), use their own tables in the database and so I believe it shouldn't be an issue.
I don't think you'd have any issue with 50docs a day, I believe there are much larger sites than that running on Umbraco although none that I've made I must admit.
As far as I know there isn't any way to exclude documents from the xml cache.
With regards to your "node.Children.Where" statement, I believe this is subject to how you are getting node in the first place. If you are using something like:
@Model.Content or @CurrentPage
Then these will be using the cache which is the most up-to-date documents, however if you are doing the approach which is against best practice and using the content service (please don't do this!) then it might be querying the database.
Thanks Nik.
If I used comments as a child document, it's simple (out of the box) but could slow the system, but maybe I should test that first and see whether it has a real impact, otherwise I need to start doing a fair amount of coding (which I would rather do when I am more familiar with Umbraco!
Thanks for all your help.
is working on a reply...