Skip to content
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

Define JSON.lower(CatValue) if JSON is available #96

Merged
merged 1 commit into from
Jan 16, 2018

Conversation

alyst
Copy link
Contributor

@alyst alyst commented Oct 30, 2017

Uses Requires.jl to define JSON.json(::CatValue) if JSON is present.

Fixes #95

@ararslan
Copy link
Member

I'm very much against adding a dependency on Requires in general, but especially in a package so far down the stack.

@nalimilan
Copy link
Member

Yes, I'd rather wait until we have optional dependencies (IIUC they should be supported in Julia 0.7).

@ararslan
Copy link
Member

IIUC they should be supported in Julia 0.7

??? As of when?

@alyst
Copy link
Contributor Author

alyst commented Oct 30, 2017

Is there a proper way to optionally define JSON.lower() in v0.6? If there's no, I think the issue is quite serious and potentially wide-spread to add JSON.jl to REQUIRE (it depends only on Compat).

Requires.jl was the first thing I found, but if its usage is discoraged, maybe @MikeInnes can add a note to README.md?

@ararslan
Copy link
Member

The use of Requires isn't discouraged in general; some packages and ecosystems prefer to use it, but the JuliaStats and JuliaData packages avoid it. It's a matter of preference and consistency.

Is there a proper way to optionally define JSON.lower() in v0.6?

No

@nalimilan
Copy link
Member

??? As of when?

I mean, when it will be released. :-)

I guess we could add a dependency on JSON until then, but that's not great and that would create a precedent for other dependencies. Last time we added a dependency on a lightweight Juno package for DataFrames, we ended up reverting it, so... Do you have an actual need for this?

@alyst
Copy link
Contributor Author

alyst commented Oct 30, 2017

Do you have an actual need for this?

Sometimes I'm just saving dataframes to json, but today I have stumbled over it while trying to draw a plot using PlotlyJS (scatter(dataframe, x=:somecategoricalcolumn, ...)).
So this issue may potentially appear in many unexpected contexts.

@alyst
Copy link
Contributor Author

alyst commented Oct 30, 2017

As an alternative, maybe something along these lines: CategoricalValue uses Ref{CategoricalPool} to refer to the pool, while JSON.lower(x::Ref) (defined in JSON itself) just prints the address of x.

@nalimilan
Copy link
Member

That's clever, but that could slow down some essential operations, so that doesn't sound great.

@nalimilan
Copy link
Member

Given that this makes PlotlyJS unusable with DataFrames with categorical columns, I guess we should add the dependency on JSON for now (without Requires).

BTW, special support for CategoricalArrays will be needed so that the ordering of levels is respected when plotting. See similar issues: plotly/plotly.js#189, vega/altair#245 and vega/vega-lite#2915.

@codecov
Copy link

codecov bot commented Jan 8, 2018

Codecov Report

Merging #96 into master will decrease coverage by 0.2%.
The diff coverage is 0%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #96      +/-   ##
==========================================
- Coverage   97.78%   97.58%   -0.21%     
==========================================
  Files           9       10       +1     
  Lines         678      662      -16     
==========================================
- Hits          663      646      -17     
- Misses         15       16       +1
Impacted Files Coverage Δ
src/CategoricalArrays.jl 0% <ø> (ø)
src/value.jl 93.02% <0%> (-1.03%) ⬇️
src/recode.jl 100% <0%> (ø) ⬆️
src/extras.jl 98.07% <0%> (ø) ⬆️
src/subarray.jl 100% <0%> (ø) ⬆️
src/pool.jl 97.95% <0%> (ø) ⬆️
src/missingarray.jl
src/nullablearray.jl 100% <0%> (ø)
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aa30eea...91e9676. Read the comment docs.

Copy link
Member

@ararslan ararslan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should use Requires here.

@alyst
Copy link
Contributor Author

alyst commented Jan 8, 2018

JSON is a hard dependency now. CI failures seem unrelated

Copy link
Member

@nalimilan nalimilan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Let's go with that since there's no other solution at this point...

@ararslan ararslan dismissed their stale review January 9, 2018 19:33

Concern addressed

@alyst alyst merged commit fa57ad2 into JuliaData:master Jan 16, 2018
@alyst alyst deleted the fix_catvalue_json branch January 16, 2018 12:24
@nalimilan
Copy link
Member

Now that Requires.jl is no longer a hack, I've used it to get rid of the dependency on JSON: #163.

@nalimilan
Copy link
Member

Actually, it turns out that Requires imposes a significant penalty on load time, which people complain about (JuliaData/DataFrames.jl#1764). On my machine, with Julia master, using JSON takes 0.05s, while using Requires takes 0.19s. So I wonder whether it wouldn't be better to use a hard dependency for now. (But it's still really annoying that we have to load JSON at all. Hopefully at some point it will be possible to define methods without loading a package.)

@ararslan
Copy link
Member

Yeah, Requires may no longer be a hack, but it still isn't a great solution. I'm fine with a dependency on JSON, as it's a common package to have installed anyway.

@nalimilan
Copy link
Member

OK, see #189.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

JSON serialization of CategoricalValue{T, R} is broken
3 participants