4 Replies Latest reply on Dec 20, 2006 7:32 PM by manik

    JBCACHE-890 - idea for consolidating meta-data on a node

    genman


      I think the JIRA issue and the API 2.0 covers most of the issue.

      http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994779

      What would be some example "flags" to eventually introduce? Data security, mutability, replication, storage, serialization strategy, data access and visibility (i.e. buddy replicated data), compression, ordering (key or children sorted), priority, locking strategy, etc.

        • 1. Re: JBCACHE-890 - idea for consolidating meta-data on a node
          manik

          On an implementation level, this makes sense. But on an interface level, I prefer individual getters/setters. I see your point mentioned on a different thread:

          "genman" wrote:


          I think a get/set(boolean) for the NodeSPI is fine. I'm more concerned about the underlying implementation: It's just likely that the set of properties of a node will expand over time. What will inevitably happen is you'll want to add more methods to NodeSPI. The idea is to add some potential for future expansion.

          If you think of the Tree as somewhat modeled off of a file system, the need for meta-data comes up time and time again. Maybe Java annotations can serve this role? But really you need something more dynamic.


          • 2. Re: JBCACHE-890 - idea for consolidating meta-data on a node
            brian.stansberry

            Somewhat off-topic, but I think we should think about a similar implementation approach for Option. I think we're going to start replicating those some day, and we're also likely to add new flags over time. If I'm thinking correctly, use of an EnumSet *may* help maintain serialization-compatibility between releases as long as we:

            1) Don't remove enum constants from the enum we use for the flags.
            2) Only add new enum constants at the end of the list; i.e. don't change order.
            3) Don't replicate a new constant if we're interoperating with a previous release that doesn't understand it.

            • 3. Re: JBCACHE-890 - idea for consolidating meta-data on a node
              manik

              Again, I'd front this with an interface that defines what these options are ... just from a programming standpoint, it is clearer to have a set of methods rather than an enum to refer to, IMO.

              • 4. Re: JBCACHE-890 - idea for consolidating meta-data on a node
                manik

                But yeah, certainly +1 for following this approach with the Options as well.