update DataFrames and CategoricalArrays dependencies #261
Conversation
|
Ah, cool, I'll remove the deprecations and then we should be good to go... that is, assuming there's not stuff in the MS SQL tests that's vital (there really shouldn't be). |
Codecov Report
@@ Coverage Diff @@
## master #261 +/- ##
==========================================
- Coverage 57.17% 52.08% -5.09%
==========================================
Files 6 6
Lines 523 576 +53
==========================================
+ Hits 299 300 +1
- Misses 224 276 +52
Continue to review full report at Codecov.
|
|
Oops, I had broken a test. I've now restored the |
ExpandingMan
changed the title
|
Sorry for the slowness here; due to #263 being merged, I created a separate |
|
For reference: 3ebc0a8 |
|
Wow, glad the big rewrite was merged already, looking forward to checking it out! Yeah, it's good of you to do backports, I probably wouldn't have even bothered 😄 |
I don't really think this is going to work, because I was only able to do the postgres tests locally and they're not all the same, but I wanted to see what would happen.
I expect that the DataFrames update is fine and won't break anything since this package only uses constructors, but I imagine that the new CategoricalArrays (which DataFrames depends on) will break things spectacularly.
I know @quinnj is working on a real overhaul of this package, but it's currently blocking dataframes for me and I thought it might not actually be difficult to get this working on modern packages (certainly true of DataFrames, likely not of CategoricalArrays).
Anyway, let's see what travis looks like... does this stuff even really get tested on travis? I guess we're about to find out...