You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you use Courier records as query parameters, Naptime uses InlineStringCodec / StringKeyCodec to parse that parameter instead of whatever StringKeyFormat you specify.
We call into CourierQueryParsershere which calls into those codecs here.
If the Courier record query parameter contains any typedef fields that have a custom StringKeyFormat defined, that StringKeyFormat is ignored. Suppose, if I have a Courier model containing a UUID field and a base64 encoded field. The base64 encoded field uses a custom StringKeyFormat. If the record is in the ID position for a GET, the base64 decoding happens correctly. If the record is in the query param position in a finder, the decoding does not happen. Also, the decoding works properly if a Scala case class is used instead of a Courier record.
The text was updated successfully, but these errors were encountered:
If you use Courier records as query parameters, Naptime uses
InlineStringCodec
/StringKeyCodec
to parse that parameter instead of whateverStringKeyFormat
you specify.We call into
CourierQueryParsers
here which calls into those codecs here.If the Courier record query parameter contains any typedef fields that have a custom
StringKeyFormat
defined, thatStringKeyFormat
is ignored. Suppose, if I have a Courier model containing a UUID field and a base64 encoded field. The base64 encoded field uses a customStringKeyFormat
. If the record is in the ID position for a GET, the base64 decoding happens correctly. If the record is in the query param position in a finder, the decoding does not happen. Also, the decoding works properly if a Scala case class is used instead of a Courier record.The text was updated successfully, but these errors were encountered: