we experience some caching problems while creating new documents via API. Let me explain the szenario:
1.we check if a document exists(via LINQ)
2. if not we wil create the new document via Document.MakeNew and Publish() it and UpdateDocumentCache() as well
when we then check again if the document exists (step 1. ) via LINQ we still receive a false even though the doc is definetly there. so at some point the cache is still active. I'm not quite sure if this is a common API issue or a LINQ issue. Or is there another method to force clearing the cache.
in umbracosttings.config we've set ContinouslyUpdateXmlDiskCache to true btw.
thanks for ths suggestion. The thing is - I don't even load a new page as such. I'm adding backend-side a new document and check if its there in the 2nd step(no requests/reload between the step 1 and 2.) and the API sais the new document is missing, but it is there and its published.
So the Meta-Tags and the web.config are irrelevant in this case I'm afraid
Recently I had exactly the same situation as you did and after some testing and debugging I discovered that the Document.Children collection (which is probably what the LINQ call is using) is not updated to reflect any newly added children (via a Document.MakeNew() ).
Instead of iterating through the list of children, try using the Document.GetChildrenBySearch( parent_id, child_name ) instead.
Assuming you know the name of the document you are looking for (and most probably you do) then calling this method will have the expected outcome.
Document.MakeNew and problem with caching
Hi guys,
we experience some caching problems while creating new documents via API. Let me explain the szenario:
1.we check if a document exists(via LINQ)
2. if not we wil create the new document via Document.MakeNew and Publish() it and UpdateDocumentCache() as well
when we then check again if the document exists (step 1. ) via LINQ we still receive a false even though the doc is definetly there. so at some point the cache is still active. I'm not quite sure if this is a common API issue or a LINQ issue. Or is there another method to force clearing the cache.
in umbracosttings.config we've set ContinouslyUpdateXmlDiskCache to true btw.
Any ideas? I appreciate your help
Thanks
Christo
PS:we use 4.5.2
Hi Christo,
I had had the same problem but now is solved:
Just add this two lines of code into the head section of your pages or masterpage:
Add to the web.config (under System.Web)
Hope this helps you too.
Sincere regards,
Eduardo Macho
Hi Eduardo,
thanks for ths suggestion. The thing is - I don't even load a new page as such. I'm adding backend-side a new document and check if its there in the 2nd step(no requests/reload between the step 1 and 2.) and the API sais the new document is missing, but it is there and its published.
So the Meta-Tags and the web.config are irrelevant in this case I'm afraid
Cheers
Hi Christo,
I made a mistake, that wasn't supposed to be here.
Regards,
Eduardo
Hi,
when we then check again if the document exists (step 1. ) via LINQ we still receive a false even though the doc is definetly there.
Set ObjectTrackingEnabled property to false to prevent LINQ from caching data
http://msdn.microsoft.com/es-es/library/system.data.linq.datacontext.objecttrackingenabled.aspx
Or consider using umbraco SQLHelper DataReader
IRecordsReader reader = Application.SqlHelper.ExecuteReader(@"");
I use datareaders.
The code you are running is ok.
HTH.
Sincere regards,
Eduardo
Hi Christo,
Recently I had exactly the same situation as you did and after some testing and debugging I discovered that the Document.Children collection (which is probably what the LINQ call is using) is not updated to reflect any newly added children (via a Document.MakeNew() ).
Instead of iterating through the list of children, try using the Document.GetChildrenBySearch( parent_id, child_name ) instead.
Assuming you know the name of the document you are looking for (and most probably you do) then calling this method will have the expected outcome.
I hope this helps.
Regards
Manos
is working on a reply...