Hello, Pavel.
Agree. Will implement it.
> 13 янв. 2021 г., в 20:28, Pavel Tupitsyn написал(а):
>
>> I propose to implicitly register classes only in the case they are sent
> to the Java side.
>
> Ok, I guess we can do this when all of the following is true
> - We are inside ExecuteJavaTask or
> I propose to implicitly register classes only in the case they are sent
to the Java side.
Ok, I guess we can do this when all of the following is true
- We are inside ExecuteJavaTask or Java service call
- FQN mapper is used (default or explicit)
- There is no BinaryIdMapper on .NET or Java side
Pavel.
> Yes, but they are registered separately for .NET and Java, please see how
> MarshallerContextImpl stores typeId->typeName mappings.
This will not change. We still will have separate type registration.
> With the proposal we put all class names in the same pile.
Implementation of type
> Classes MUST be registered to be used in compute or cache.
Yes, but they are registered separately for .NET and Java,
please see how MarshallerContextImpl stores typeId->typeName mappings.
With the proposal we put all class names in the same pile.
Now imagine that the user has a cluster with C
Hello, Pavel.
> Imagine that some Ignite user has lots of .NET and Java classes being stored
> in cache, used in compute,
Classes MUST be registered to be used in compute or cache.
So, in your example, user registered classes by hand, already.
> Let's add a flag like BinaryConfiguration.AssumeS
Nikolay,
I agree with your proposal, with one addition:
this behavior must be disabled by default for compatibility reasons.
Imagine that some Ignite user has lots of .NET and Java classes being
stored in cache,
used in compute, etc. Now with the proposal implemented, all .NET classes
are registe
Hello, Pavel
My proposal is the following:
*When Ignite configured with FQN NameMapper.*
And user invokes
1. Service method from .Net to Java.
2. Compute methods `ExecuteJavaTask`, `ExecuteJavaTaskAsync`
3. Cache operations.
Ignite should implicitly register types both for .Net and Java platf
Nikolay,
As I understand, you insist on changing the default behavior, is this
correct?
On Tue, Jan 12, 2021 at 9:51 PM Nikolay Izhikov wrote:
> Hello, Igor, Pavel.
>
> Thanks for the feedback
>
> > Agree with Pavel, this should be disabled by default.
>
> Right now, Ignite, by default, forcin
Hello, Igor, Pavel.
Thanks for the feedback
> Agree with Pavel, this should be disabled by default.
Right now, Ignite, by default, forcing users to enlist every single value
object they have in project in the config.
Do you think it’s a right way to go?
> To me it looks pretty dangerous as use
Agree with Pavel, this should be disabled by default.
To me it looks pretty dangerous as users do not explicitly control what's
going to be
registered and it could lead to hard-to-debug mistakes when wrong classes
get
registered or with wrong names. Also it can be hard to use with classes
that sho
Nikolay,
I think this behavior should be opt-in - let's add a flag to
BinaryConfiguration.
Registering every .NET type as a Java type can lead to typeId collisions
and break existing user code,
so we can't enable this by default.
Ignite stores typeId -> className mappings separately for Java and
Hello, Igniters.
Currently, in case of usage .Net platform client it’s required for the user to
explicitly register each custom type.
```
_marsh = new Marshaller(new BinaryConfiguration
{
TypeConfigurations = new List
{
new BinaryTypeConfiguration(typeof (Address)),
new B
12 matches
Mail list logo
