Re: Types.OTHER

> On Jun 15, 2020, at 11:47 PM, Dirk Lattermann <[email protected]> wrote:
> 
> On Mon, 15 Jun 2020 14:49:05 +0300
> Andrus Adamchik <[email protected]> wrote:
> 
>>> On Jun 9, 2020, at 5:54 PM, John Huss <[email protected]> wrote:
>>> 
>>> 2) Regarding skipping parsing when just going straight back out
>>> again to serialization - I have felt the reluctance (like you) of
>>> parsing this in those cases. But one thing to think about is that
>>> the parser/serializer (let's say Jackson in this case) may have
>>> special rules for how types are outputted like pretty/minified,
>>> sorted/unsorted, string/number (for BigDecimal). So skipping that
>>> parse/serialization may not actually be desirable, at least not in
>>> every case.  
>> 
>> Was discussing this offline with Nikita and stumbled on what can be a
>> good solution:
>> 
>> 1. Cayenne would provide a set of "unparsed" wrapper types (Wkt,
>> Json, etc.) and the JDBC/SQL machinery around them (ExtendedType,
>> SqlTreeProcessor). 2. A user who needs a parsed version would create
>> their own types (e.g. WktParsed, JsonParsed), and would connect them
>> to Cayenne via a custom ValueObjectType [1] (e.g.
>> ValueObjectType<WktParsed, Wkt>).
>> 
>> Such a two-tier approach would allow the users to map persistent
>> properties to anything they want without much effort and use their
>> preferred third-party parsers. While Cayenne would do all the DB-side
>> heavy lifting. The two parts are cleanly separated.
> 
> Hello,
> 
> I'm not familiar with the ValueObjectType, so what I'm writing here
> might be irrelevant, but at which point is the decision taken that the
> JSON column needs to be updated? Doing this in Hibernate using a
> CustomType, it is important that the mapped (deserialized) type has a
> correct equals method, and only if the value differs from the original
> value, then the serializer (e.g., Jackson) will be invoked and the
> resulting string (or jsonb) column will be updated in the database.
> It will likely be more efficient doing updates that way instead of
> always serializing and comparing the serialized value against the
> previous db state.
> 
> But, as I said, please ignore this statement if it doesn't make sense
> in the context here.
> 
> Greetings, Dirk


It does make sense, and there are issues around objects not implementing ".equals()" in a reliable way (e.g. [1]). Luckily in this case value comparisons run prior to the ValueObjectType invocation. So we should be good.

Andrus

[1] https://lists.apache.org/thread.html/r4b565a14c814775400dd93e362cc9be0c5943c07d25b29174c7621b7%40%3Cdev.cayenne.apache.org%3E