Bruce, this was not aimed at Darrel to do. I was just counter-proposing
that I prefer a different approach to solving the problem.
And yes, all new features are starting to become big changes. I still
think that the proposal that Darrel has made, could be a byproduct of a
"Serialization Framew
While I like the idea of a non-static & more flexible serialization
service I don't think it's reasonable to foist that onto Darrel because
it's a great deal of work.
On 1/15/19 2:29 PM, Darrel Schneider wrote:
Dan, we still want a "class name" but it no longer has to be an actual name
of a j
Dan, we still want a "class name" but it no longer has to be an actual name
of a java class.
It can now be just a logical "type name". For two PdxInstances to be equal
they need to have the same class name.
So we really do just want a flag that says: never deserialize this
PdxInstance.
Anil suggest
Darrel to better understand what you are asking for:
I understand that you want the following:
byte[] -> PdxInstance
and not
byte[] -> PdxInstance -> Pojo
The `read-serialized=true` flag is a single flag that "rules them all"
which does not make sense anymore and something that is seemingly
If I understand this right, you are talking about a way to create a
PdxInstance that has no corresponding java class. How about just a
RegionService.createPdxInstanceFactory() method that doesn't take a
classname, and therefore has no corresponding java class? It seems a
PdxInstances without a clas
Even before the JSON pdx support we had internal support for a PdxInstance
that deserializes as a PdxInstance.
This is just adding an external api for that already existing internal
feature. So it is pretty simple to do if we can figure out how to name it.
On Tue, Jan 15, 2019 at 11:18 AM Galen O
I suspect Udo is remembering something we both had to deal with, which is
that the lack of values to get/put PDXInstances on Regions make some
patterns difficult. In internal code, we have to set some thread-locals to
get serialized values out, and in general, I think that setting
pdx-read-serializ
I like the idea of adding support to the region configuration that lets
users control how it stores the data. But even if we did that, and you are
correct that it would be much more work, I don't think it would address
this issue or remove the value of a PdxInstance that always deserializes to
a Pd
Darrel, thank you for this.
I would like to propose a counter-proposal.
Instead of introducing another PDXInstance type, why don't we improve
the serialization framework itself? I know my proposal is most likely
going to take a little more effort than adding a new type, but I believe
it is le
As part of GEODE-6272 we realized we need a way to use a PdxInstance as key
for a Region entry. The problem with the current PdxInstance behavior is
that in some members the key may be seen as a PdxInstance and in others
seen as an instance of a domain class. This inconsistency can lead to
problems
10 matches
Mail list logo
