IGNITE-25090 Move binary classes to binary-api#12362
Conversation
| ThreadLocal.withInitial(BinaryContextHolder::new); | ||
|
|
||
| /** Binary context supplier. */ | ||
| private static Supplier<BinaryContext> BINARY_CTX_SUPPLIER; |
There was a problem hiding this comment.
I have an idea for the future of how to get rid of this supplier.
I scanned the code and found that IgnitionEx.localIgnite().context().cacheObjects().binaryContext() call returns the same instance of BinaryContext as arrives to GridBinaryMarshaller constructor.
So we could replace this vague trick with supplier initialized from KernalContext implementations with a static atomic reference which we set from the constructor.
But ultimately one would want to see this static BINARY_CTX stuff refactored to BinaryUtils or to some separate component.
|
|
||
| if (schema == null) { | ||
| BinaryTypeImpl meta = (BinaryTypeImpl)cacheObjProc.metadata(typeId); | ||
| BinaryTypeImpl meta = (BinaryTypeImpl)metadataProvider.apply(typeId); |
There was a problem hiding this comment.
I think you could use BinaryContext#metadata method to obtain BinaryTypeImpl here. From what I see call to BinaryContext#metadata goes exactly to cacheObjProc#metadata(int) in the end. If this is true then we don't need metadataProvider parameter at all.
|
2 participants
Thank you for submitting the pull request to the Apache Ignite.
In order to streamline the review of the contribution
we ask you to ensure the following steps have been taken:
The Contribution Checklist
The description explains WHAT and WHY was made instead of HOW.
The following pattern must be used:
IGNITE-XXXX Change summarywhereXXXX- number of JIRA issue.(see the Maintainers list)
the
green visaattached to the JIRA ticket (see TC.Bot: Check PR)Notes
If you need any help, please email dev@ignite.apache.org or ask anу advice on http://asf.slack.com #ignite channel.