by design eoeditingcontext 's have a fetch timestamp default is 1 hour that effectively creates an in-memory caching system for eos . this works great for users browsing through pages in the app . however , experience has shown that background eof tasks are performing updates based on the state of other eos , and thus we want to this is a long-running task . the last thing i want to do is perform a long running task with stale eos , so we lazily create a fetch timestamp of the current time when we create the first ec and thus ensure fresh data . secondly , we continue , by default to use this timestamp for the duration of the task since experience has shown that by doing so we can prevent unnecessary database fetching especially when our task is adding lots of items to a single relationship in batches . however if you want fresh data each time you create an ec in your task , feel free to set the fetch time stamp to the current time in your task each time you create a new ec . for r-r ec 's we prefer fresh data on new pages . however for long running tasks , it is often best pick a single point in time , usually when the first ec is created as the timestamp lag . this works well when we are iterating and making new ec 's especially if we are adding 100 's of items to a relationship and cycling ec 's concode_field_sep EOObjectStore _parentObjectStore concode_elem_sep Long _taskEditingContextTimestampLag concode_field_sep EOObjectStore parentObjectStore concode_elem_sep void setParentObjectStore concode_elem_sep EOEditingContext newEditingContext
long function ( ) { if ( _taskEditingContextTimestampLag == null ) { _taskEditingContextTimestampLag = System . currentTimeMillis ( ) ; } return _taskEditingContextTimestampLag . longValue ( ) ; }