wip

Signed-off-by: Attila Mészáros <[email protected]>

Author: csviri

docs/content/en/docs/documentation/reconciler.md

@@ -245,7 +245,7 @@ needs to be set to `false` you can use an explicit caching approach:
           StatusPatchPrimaryCacheCustomResource primary,
           Context<StatusPatchPrimaryCacheCustomResource> context) {
 
-    //   
+    // cache will compare the current and the cached resource and return the more recent. (And evic the old)   
     primary = cache.getFreshResource(primary);
 
     // omitted logic  
@@ -278,7 +278,7 @@ As shown in the example above, it is up to you to provide a predicate to determi
 In other words, when to evict the resource from the cache. Typically, as show in the [integration test](https://github.com/operator-framework/java-operator-sdk/blob/main/operator-framework/src/test/java/io/javaoperatorsdk/operator/baseapi/statuscache/primarycache)
 you can have a counter in status to check on that. 
 
-Since all of this happens explicitly, you cannot use this approach for managed dependent resources and workflows; 
+Since all of this happens explicitly, you cannot use this approach for managed dependent resources and workflows (you can still use not managed); 
 Since passing of the primary resource to the dependent resource always comes directly from the underlying informer event
 source cache.