I agree with you that it seems odd to support some JSON primitives and not others.
Are you suggesting a config option that would support all JSON primitive types? Or just int, string, and true? If all primitive types are supported, I like this option! Otherwise, having to remember which types are supported vs. not supported is an added layer of complexity that I would rather not think about. Can you give a more detailed example of why wrapping null and false would be a breaking change? Thanks for your help! Alex On Monday, April 29, 2019 at 11:17:39 AM UTC-4, Jeremy Evans wrote: > > On Monday, April 29, 2019 at 7:45:31 AM UTC-7, [email protected] > <javascript:> wrote: >> >> Thanks for the quick response Jeremy. Very helpful. >> >> Our use case is a generic attributes table with the following columns: >> type VARCHAR >> value JSONB >> >> The name or type of the attribute is stored in the "type" column and the >> attribute value is stored in the "value" column. >> >> Each attribute value can either be an Int, Bool, or String. In order to >> capture the type of the attribute value while using a single column, we >> chose to use a JSONB column and store JSON primitives in that column. >> >> It is sort of a hack to capture both the value and type without having a >> separate column for each attribute. >> >> As an alternative, we could store all values as a "string" and do some >> sort of type inference when retrieving the data. >> >> If you have any other ideas on how to achieve the same effect, I'm all >> ears. >> > > What you are doing sounds reasonable and is something that it would be > nice to support. I think for integer, string, and true, we could have a > wrapper that mostly works transparently. Unfortunately, I don't see a way > to wrap null or false in a way that would work. Those are currently treated > as nil/false, and wrapping them would give you an object that is not > nil/false, which will change the object's behavior in a boolean context. I > think it would seem odd to support some JSON primitives and not others. > > I think the best way to move forward on this is to keep the current > behavior by default, but add an option for wrapping json primitives. Users > who turn that option on will know they have to deal with the issues. That > wouldn't make 5.20.0, but is something that could be done in 5.21.0. > Thoughts on that approach? > > Thanks, > Jeremy > -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
