We generally do use separate regions for separate data types that have different qualities of service. As long as we don't think there will be a proliferation of regions due to the ":" convention it shouldn't be too bad. There is an issue with dynamic creation of regions in general. New nodes that come up after the Region was dynamically created won't know about the Region and won't create it. That's the main reason I tend to avoid dynamic Region creation in my code.
-- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: +1-631-835-4771 On Thu, Mar 2, 2017 at 4:23 PM, ggreen <g...@git.apache.org> wrote: > Github user ggreen commented on a diff in the pull request: > > https://github.com/apache/geode/pull/404#discussion_r104033312 > > --- Diff: > geode-core/src/main/java/org/apache/geode/redis/internal/RegionProvider.java > --- > @@ -259,6 +307,16 @@ public void > createRemoteRegionReferenceLocally(ByteArrayWrapper > key, RedisDataTy > > private Region<?, ?> getOrCreateRegion0(ByteArrayWrapper key, > RedisDataType type, > ExecutionHandlerContext context, boolean addToMeta) { > + > + String regionName = key.toString(); > + > + // check if type is hash TODO: remove > --- End diff -- > > Hello @galen-pivotal , > > You mean why do we need to create a region for an object, correct? > If you mean that, then yes, I guess we could just use the same > ReDiS_HASH region for objects and non-objects. Of course, there are pros > and cons for each approach. > > Prior to this pull request, the Redis adapter created objects for all > HASH keys. I originally liked the idea of limiting the creation of regions > to just HASH objects. Having a separate region when objects are used can > provide additional flexibility. For example, we could pre-define the > region with unique definitions based on a given use case. > > While testing with Spring Data Redis example, I created a "companies" > region with my desired properties that were totally over my control. These > regions for objects could be managed separately from the default ReDiS_HASH > region. For example, we could different data policies, disk stores, > listeners, etc. > > What do you think? > > > --- > If your project is set up for it, you can reply to this email and have your > reply appear on GitHub as well. If your project does not have this feature > enabled and wishes so, or if the feature is enabled but not working, please > contact infrastructure at infrastruct...@apache.org or file a JIRA ticket > with INFRA. > --- >
