-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HStore implementation to parse NULL values and filter them out from the HStoreList #215
base: master
Are you sure you want to change the base?
Conversation
…he HStoreList. This has a minor side-effect where hstores with NULL values will not really round-trip properly, i.e. if we read the following from the DB "foo" => "bar", "fooNull" => NULL we will get the following in Haskell [("foo", "bar")] and when stored back to the DB, it will get converted to: "foo" => "bar" This results in minor loss in fidelity. However, for all practical purposes, the absence of a key, and the key being assigned a NULL value is the same thing. How many programs out there would really be doing different things based on this condition?
@lpsmith what do you think of this approach? Pragmatically equivalent and doesn't introduce |
I can't say I am overly enthusiastic about this filtering approach, but maybe I am softening on it somewhat. I would probably prefer a breaking interface change to the filtering approach here. While I find the HStoreV2 approach that you suggested acceptable, I am undecided regarding my preference between that and a breaking interface change. HStoreV2 is probably the "right thing", but a breaking change would avoid some ugliness in the longer run, though it might create some other ugliness. |
From a usage standpoint, both HStoreList and HStoreMap return a Maybe
whenever a key is looked up. In that sense they already have a way to
handle NULLs. There isn't much to gain by changing HStoreList from [(Text,
Text)] to [(Text, Maybe Text)]. Except one thing -- the ability to know if
the key had a NULL value or was truly missing from the HSTORE.
I dont care about the pedantic difference between a missing key and a
null-value key. What are your thoughts?
…On 12-Jun-2017 2:36 AM, "Leon P Smith" ***@***.***> wrote:
I can't say I am overly enthusiastic about this approach, but maybe I am
softening on it somewhat. I would probably prefer a breaking interface
change to the filtering approach here. While I find the HStoreV2 approach
that you suggested acceptable, I am undecided regarding my preference
between that and a breaking interface change. HStoreV2 is probably the
"right thing", but a breaking change would avoid some ugliness in the
longer run, though it might create some other ugliness.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#215 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABu0RIPIW-gpGtpjtKz3_iLdDvcJiYwks5sDFbSgaJpZM4N2TzU>
.
|
@lpsmith did you get a change to decide on this? |
@lpsmith any update on this? |
Fixes #215 Related to #214
This has a minor side-effect where hstores with NULL values will not really
round-trip properly, i.e. if we read the following from the DB
we will get the following in Haskell
and when stored back to the DB, it will get converted to:
"foo" => "bar"
This results in minor loss in fidelity. However, for all practical purposes,
the absence of a key, and the key being assigned a NULL value is the same
thing. How many programs out there would really be doing different things based
on this condition?