Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    #16
    No, this doesn't make sense because the framework has only partial caches of datasets. There is not enough information for the framework to correctly make decisions like this. So again, no enhancement is needed (or possible).

    Comment


      #17
      I'm totally confused now, please provide clarification. The previous Isomorphic support stated:

      "cacheAllData does not require you to maintain same criteria etc for all consumers. It loads all data from the DataSource up front, and then provides subsets of it (that match provided criteria, sort etc) to various components on demand."

      So I thought this meant that the framework does cache everything ("loads all data from the DataSource up front").

      The latest post from Isomorphic support indicated that it only partially caches.

      Note: From what I read from the java docs, I thought the framework only partially caches. I believe the exact behaviour is it only catches the first fetch based on the first fetches criteria etc. The rest of the subsequent calls for fetch will be working of the first dataset. However, the previous Isomorphic support person seemed to disagree with me and stated that the framework loads "ALL" data from the DataSource up front.

      Comment


        #18
        You can get a lot of clarity from reading docs.

        cacheAllData is a property that can be set. When it is set, the DataSource caches all data up front.

        The default behavior is not to cache all data up front (as covered in the QuickStart Guide).

        Comment


          #19
          Okay so it sounds like:

          "No, this doesn't make sense because the framework has only partial caches of datasets."

          means the the current framework is coded to only do partial caches, however, the framework supports caching of all data.

          Still sounds like full caching during an invalidateCache is possible based on what is being discussed and it would seem to me that logic could be created in the framework to make decision points on when to cache or not (perhaps with some new interfaces which a customer can make concrete from their code to allow passing of data for the decision engine).

          Comment


            #20
            Sorry, we really have no idea what you mean, but if you still perceive a possible framework enhancement here, we would recommend you review the cacheAllData documentation again along with the ResultSet documentation, and then re-explain your suggestion starting from scratch.

            In particular, be sure to explain what is happening from an end user's perspective - the goal of the whole interaction.

            Comment


              #21
              Probably best left for an enhancement indeed. I don't think enhancement requests would be in the Q&A section. Should I start a new thread in the wishlist when i get a chance to write up my idea more formally?

              Comment


                #22
                A new post is fine, please just make sure to carefully read the suggested documentation first.

                Comment

                Working...
                X