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 [email protected] or file a JIRA ticket
with INFRA.
---
