| Re: [nosql-dev] The right way to get DefaultDocumentEntityConverter instance. |
Hi Otavio,
I think the simplest way would be to introduce default methods in the AttributeConverter:
default Y
convertToDatabaseColumn(DocumentEntityConverter c, X x) {
return convertToDatabaseColumn(x);
}
default X convertToEntityAttribute(DocumentEntityConverter
c, Y y) {
convertToEntityAttribute(y)
}
And call these methods from the API, like:
Object attributeConverted =
attributeConverter.convertToEntityAttribute((Y) value.get());
-->
Object attributeConverted =
attributeConverter.convertToEntityAttribute(converter, (Y)
value.get());
this would preserve the compatibility and allow to override the
method when converter is needed.
Cheers,
Dmitry
Indeed, we did not think about the polymorph design yet in the whole project.
It could be an opportunity to do it.
We have a
DocumentEntityConverterinterface where we convert to/from Java entities but without any polymorph around it.I recommend writing down either a proposal or what you need with samples regarding the next steps.
On Fri, Apr 29, 2022 at 11:05 AM Dmitry Repchevsky via nosql-dev <nosql-dev@xxxxxxxxxxx> wrote:
_______________________________________________Hi Otavio,
Yes, I read the spec. :-) The question was that usage of SPI for the polymorphism purpose is incorrect from design point of view.
IMO SPI is for the extending a common purpose types, for instance I use java.time.Period reader (and hope all JAXB types will be included in jnosql).
On the other hand on the "mapping layer", the only way to add a converter via annotation is the @converter (sorry for the tautology).
My question is about is there any way to deserialize the instance programmatically (like JsonbBuilder.create().fromJson(reader, MyClass.class)).
Ideally, would be to get a current DefaultDocumentEntityConverter.
Does it make sense?
Dmitry
On 4/29/2022 10:04 AM, Otavio Santana wrote:
Hey, how are you?
Indeed we have two ways.
It is because Jakarta NoSQL has two layers: communication and mapping.
In the communication layer, you have the option of using SPI to teach a custom type:
https://www.jnosql.org/spec/#_make_custom_writer_and_reader
Therefore, the communication will convert the type in the database layer.
In the mapping it follows the same idea around the JPA converter:
https://www.jnosql.org/spec/#_convert
Please, let me know if it helps.
If not, please, don't hesitate to ask questions and give feedback as much as possible.
Suppose it is not clear, excellent! We can improve our documentation as well.
Does it help you?
Thank you for your participation here.
On Thu, Apr 28, 2022 at 6:12 PM Dmitry Repchevsky via nosql-dev <nosql-dev@xxxxxxxxxxx> wrote:
Hello,
The @Convert(AttributeConverter.class) is a simple way to provide custom
serialization / deserialization mechanism similar to the JsonbAdapter.
Unfortunately, unlike JSON-B, Jakarta NoSQL has no custom Serializers
/Deserializers support. Deserializers in JSON-B are more useful for the
polymorphism, because they provide the context so I can deserialize the
object of choice easily once I decide on the type.
What is the correct way to to this from the custom converter class?
May I have an access to the DefaultDocumentEntityConverter?
Kind regards,
Dmitry
_______________________________________________
nosql-dev mailing list
nosql-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/nosql-dev
--
Otávio Santana
nosql-dev mailing list
nosql-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/nosql-dev
--
Otávio Santana