Cole-Greer commented on code in PR #3433:
URL: https://github.com/apache/tinkerpop/pull/3433#discussion_r3393413568
##########
gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/driver/remote/DriverRemoteConnection.java:
##########
@@ -214,6 +216,18 @@ public static DriverRemoteConnection using(final
Configuration conf) {
}
}
+ @Override
+ public ProviderDefinedTypeRegistry getPdtRegistry() {
+ return pdtRegistry;
+ }
+
+ /**
+ * Sets the {@link ProviderDefinedTypeRegistry} for registry-based
dehydration in the gremlin-lang translator.
+ */
+ public void setPdtRegistry(final ProviderDefinedTypeRegistry pdtRegistry) {
Review Comment:
There were a few issues with the wiring of automatic cases which have been
addressed, but there's still a caveat, here's the current state:
Dehydration (outbound — sending a typed object as a PDT): Fully automatic,
no setPdtRegistry needed.
- @ProviderDefined-annotated classes are converted automatically —
GremlinLang detects the annotation and dehydrates with no registry involved.
- Adapter-registered types are also handled automatically:
DriverRemoteConnection now defaults its registry to an SPI-discovered
ProviderDefinedTypeRegistry.create(), so any ProviderDefinedTypeAdapter
registered via META-INF/services is picked up. (If both apply, a registered
adapter takes precedence over the annotation, so a user can override
annotation-derived behavior.)
Hydration (inbound — reconstructing a typed object from a response):
Automatic for adapter-discoverable types.
- The default GraphBinaryMessageSerializerV4 now wires the SPI-discovered
registry into the reader, so types with a ProviderDefinedTypeAdapter on the
classpath hydrate back into their typed form with zero configuration.
- Types with no registered adapter come back as a raw ProviderDefinedType
(name + fields) — which is the intended default and works without any setup.
- There is no mechanism to automatically pick up annotated classes on the
inbound path, adapters must be registered for hydration.
When you still need setPdtRegistry (or registry.register(...)):
1. Annotation-only hydration — a @ProviderDefined class with no adapter.
Annotations are passive in Java (unlike Python decorators, they don't
self-register), so SPI can't discover them for the inbound path. Calling
registry.register(MyType.class) synthesizes an adapter from the annotation.
Note these types
still dehydrate automatically; it's only hydration that needs the
registration.
2. Per-connection or programmatic registries — e.g. connecting to multiple
graphs with different PDT schemas, or building a registry by hand rather than
via SPI.
So for the common case (provider ships adapters via SPI, or users only need
raw ProviderDefinedType values), no manual wiring is required. setPdtRegistry
remains as the override for annotation-only hydration and custom/per-connection
registries.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
