Uploaded image for project: 'Couchbase .NET client library'
  1. Couchbase .NET client library
  2. NCBC-564

Respect JsonSerializer settings for deserialization

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 1.3.7
    • Fix Version/s: 1.3.8
    • Component/s: library
    • Labels:
      None

      Attachments

      For Gerrit Dashboard: NCBC-564
      # Subject Branch Project Status CR V

        Activity

        Hide
        jmorris Jeff Morris added a comment -

        Thanks for submitting bchavez!

        Show
        jmorris Jeff Morris added a comment - Thanks for submitting bchavez!
        Hide
        bchavez bchavez added a comment - - edited

        Thanks, I also am also (slightly off topic) having problems with this section of code:

        if (!IsArrayOrCollection(typeof(T)))

        { value = DocHelper.InsertId(value, key); }

        I am managing all the document IDs myself in my application. But DocHelper keeps interfering with my ID during deserialization. Is there a way we can possibly set a flag that wont interfere with my JSON ?

        One example: All my domain objects have a strongly typed Guid as their ID.

        The KEY to an Account object is "acct:aaaa-bb-cc-dd".

        POCO in C#:
        public class Account{
        public Guid Id

        {get;set;}

        }

        I format the key to this object inside my App; however, during deserialization DocHelper interferes with the JSON by injecting the KEY: "acct:aaaa-bb-cc-dd" into the ID property in the JSON before deseralization.

        So when Newtonsoft deserializes the JSON with the injected DocHelper Id:Key:"acct:aaaa-bb-cc-dd" cannot be converted to a Guid because of the prefix "acct:" is an invalid Guid format. I'd prefer the SDK not interfere with any of my ser/deser JSON.

        Perhaps we can add some flag that can short circuit the DocHelper injection?

        Thanks,
        Brian

        Show
        bchavez bchavez added a comment - - edited Thanks, I also am also (slightly off topic) having problems with this section of code: if (!IsArrayOrCollection(typeof(T))) { value = DocHelper.InsertId(value, key); } I am managing all the document IDs myself in my application. But DocHelper keeps interfering with my ID during deserialization. Is there a way we can possibly set a flag that wont interfere with my JSON ? One example: All my domain objects have a strongly typed Guid as their ID. The KEY to an Account object is "acct:aaaa-bb-cc-dd". POCO in C#: public class Account{ public Guid Id {get;set;} } I format the key to this object inside my App; however, during deserialization DocHelper interferes with the JSON by injecting the KEY: "acct:aaaa-bb-cc-dd" into the ID property in the JSON before deseralization. So when Newtonsoft deserializes the JSON with the injected DocHelper Id:Key:"acct:aaaa-bb-cc-dd" cannot be converted to a Guid because of the prefix "acct:" is an invalid Guid format. I'd prefer the SDK not interfere with any of my ser/deser JSON. Perhaps we can add some flag that can short circuit the DocHelper injection? Thanks, Brian
        Hide
        jmorris Jeff Morris added a comment -

        Yes, the proper way to do this would be to create another ticket as a feature request.

        A couple of criterion to consider:
        a) The default should be the current behavior - don't break existing users
        b) It's configurable through the app.config
        c) Includes set of unit tests showing default and "set" behavior

        As always, if you would like to take a stab at it and submit a PR, go for it

        -Jeff

        Show
        jmorris Jeff Morris added a comment - Yes, the proper way to do this would be to create another ticket as a feature request. A couple of criterion to consider: a) The default should be the current behavior - don't break existing users b) It's configurable through the app.config c) Includes set of unit tests showing default and "set" behavior As always, if you would like to take a stab at it and submit a PR, go for it -Jeff
        Hide
        bchavez bchavez added a comment -

        This is awesome. Thank you. Yea, I'll likely take a stab at it later today.

        Show
        bchavez bchavez added a comment - This is awesome. Thank you. Yea, I'll likely take a stab at it later today.
        Hide
        jmorris Jeff Morris added a comment -

        >> I'd prefer the SDK not interfere with any of my ser/deser JSON.

        Agreed, not sure why it enforces it TBH.

        >>This is awesome. Thank you. Yea, I'll likely take a stab at it later today.

        Cool, have fun!

        Show
        jmorris Jeff Morris added a comment - >> I'd prefer the SDK not interfere with any of my ser/deser JSON. Agreed, not sure why it enforces it TBH. >>This is awesome. Thank you. Yea, I'll likely take a stab at it later today. Cool, have fun!
        Hide
        jmorris Jeff Morris added a comment -

        86fd1c588df15611b557bfa7e401581e005c188e

        Show
        jmorris Jeff Morris added a comment - 86fd1c588df15611b557bfa7e401581e005c188e

          People

          • Assignee:
            jmorris Jeff Morris
            Reporter:
            bchavez bchavez
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes