Plenty of articles explain how to use a document's ETag to opt into optimistic concurrency behavior for that document.
It appears that a container itself may also have an ETag. However, there's no explicit mention of whether that ETag reflects changes to the documents inside the container, or only to the definition of the container itself.
In short, is it possible (and supported) to use the etag property of a CosmosDb container to prevent concurrent updates across the entire container?
I'm similarly curious about the timestamp property. Is that updated when any document changes, or just the container itself?
is it possible (and supported) to use the etag property of a CosmosDb
container to prevent concurrent updates across the entire container?
No, the etag property at the container level cannot be used to prevent concurrent updates across the entire container.
I'm similarly curious about the timestamp property. Is that updated
when any document changes, or just the container itself?
ts property at the container level is only updated when that container is updated. When you update a document, only that document's ts property gets updated not that of the container.
Related
Is there a web API to find containing block of an element?
Containing block official definition is mentioned here https://www.w3.org/TR/CSS22/visudet.html#containing-block-details . I am hoping each element's containing block info is stored somewhere and can be retrieved using some web api.
"Containing block" is an abstract concept, not a concrete one. For this reason, there aren't any APIs in either CSSOM or cssom-view for "retrieving" the containing block of an element, and even if there were, you wouldn't be able to read, change, or render it anyway, so this information isn't going to be of any use to you as an author.
In all likelihood, though, you're asking this not because you're trying to manipulate this information, but because you just want to be able to visualize an element's containing block for debugging purposes. That's why it's something I think all browser developer tools should have: because your use case is served by developer tools, not cssom-view.
I am migrating some contents from one alfresco 4.2 repository to other alfresco 5.2 repository using Apache chemistry Open CMSI API.
I am also migrating some metadata from Old repository along with content and adding it as a aspect in new repository.
But after migration one sys:incomplete aspect is getting applied for some contents.
Can anyone please explain the meaning of this aspect and why it is getting applied??
Because of this aspect I am getting some challenges for Advanced Search functionality.
Refer this comment
It is indeed the case that the 'sys:incomplete' aspect is not applied
if you "only" change the type of a node. The relevant policy
(IncompleteNodeTagger) is only triggered by node creation, property
updates, aspect updates, creation and deletion of (child)
associations. Unfortunately, changing the type is - as far as at the
moment - the only change to an object that does not trigger one of
these policies (apart from deletion, which is irrelevant for this use
case).
From this question
I'm trying to create a custom grid in Rally to filter Tasks on the tags of both the task parent and/or the parent of the parent. I'm able to get the parent's tag, but not the syntax of the parent of the parent.
Unfortunately you'll have a hard time doing this with the custom grid app. The problem is that the WorkProduct field that represents the Task's parent is of type Artifact since it can be either a story or a defect. But Artifact doesn't have a Parent field.
It should be possible to write an app to do this though, by querying from the other direction- find features with a specific tag and load their children, find stories with a specific tag, and then load all of the children tasks associated with those stories...
I have a site built in Drupal 6 that requires a number of blocks that are only visible to certain roles or on specific pages. Normally, I would use the block configuration settings to control page and role visibility. However I recently ran across the context module that effectively splits the site into "sections" or "groups" of related attributes.
My question is: When is it appropriate to control block visibility from context rather than the block configuration settings? Should I only use one or the other or a combination of both?
these are different approaches meant for different use cases, but they are not mutually exclusive.
context indeed splits the site into different contexts (and there is also the possibility of context types). and that is effectively its use case: context-based block showing/positioning.
however context won't check for user roles nor multilingual settings (i18n). block supports these cases (and you can combine both context and block to show something on a context depending on user role).
block also allows users to choose whether they want to see the box or not.
my final answer is: combine instead of choosing.
There is no hard and fast rule for when to use core block placement, and when to use context. In general though, if you have a lot of blocks, with different and complex visibiity logic, context will make things more manageable. Additionally, contexts can be exported to code, which allows one to more easily track block configurations in version control. When storing contexts in code, this also allows changes to blocks to be deployed to a production site by simply updating the code, rather than needing to log in and manually move things around via the UI.
Recently I found out that there are several things that one can do to massivly slowing down a Flex application. One of those things is the use of many nested layout containers. Another thing which is very problematic is the usage of lot's of relative positioning and sizes.
I do understand that there is a very big amount of calculations that must be done before the layout elements can be displayed. What I do not understand is why the rendering is done all the time. With a certain amount of complexity in your layout your CPU usage is 100% all the time even if there are no changes in the layout.
Why is that? And what can I do about that (without redoing the whole layout)?
Thanks a lot!
It is true that nested containers do slow things down, but I haven't yet been able to get the CPU usage up to 100% yet. The framework should only recalculate the layout of a component after its invalidateDisplayList() has been called. Calling this schedules a call to updateDisplayList, in which the layout of a container is calculated. Consequently, the display lists of the component's children are invalidated as well.
Besides doing it yourself, the displayList can be invalidated by the framework for a variety of reasons. For instance, it is always invalidated after invalidateProperties(). It could be that you have something that accidentally invalidates the display list of some high-level container all the time, thus propagating it down to its children.
Do you have any code to share? And what kind of a system are you running?
Any other solution other then refactoring your layout and not use many nested elements means change the way adobe framework works, and you do not want to do it !
My suggestion although might be painfull , change your view components , use absolute size and location where possible , do not nest too many elements .
The reason for the bottle neck with nested components is that the invalidate functions go 2 way , first up the tree from the changed component to the root , then from the root to all its nested elements , that whats taking your cpu .
Finally I found out what exactly the problem with our application was!
The problem was not that we used lot's of nested layout containers. I found out that there was a third party component that we use which attaches an event listener to the ENTER_FRAME-Event. Unfortunately this component does not shutdown properly so the event listener never gets removed. One thing this event triggers is a call to invalidateDisplayList(). I found out that the ENTER_FRAME-Event occurs very often (I still don't know why exactly this happens) and because of that the whole layout is recalculated over and over again. Because of the nested structure of our layouts this is a very time consuming thing to do and therefore the CPU gets very busy!
I could solve this problem by adding some extra code to the component that properly removes the event-listeners if they are no longer needed. The result of that has been that the application now does not need any CPU-power when in idle-mode. Hooray!!