-
Notifications
You must be signed in to change notification settings - Fork 1
Issues about this prototype #1
Comments
@bkamins If you have a few minutes, may I ask you for some help in reviewing what I have done here? I went ahead and try to implement the I have summarized the issues above. Thank you very much 🙏 |
This is very nice. What I can recommend to check it (sorry for not being super-constructive with a concrete implementation) is to take the tests from DataFrames.jl and check what gets broken here. As a general question. When you have |
Can you check if Also in general - all "core" types (like Therefore - the pattern I would recommend is to make sure that you handle the constructors of these types explicitly (maybe the For example
|
This is a great question. Generally speaking, I don't mind losing the original identity after certain operations. For example, doing joins would usually produce a completely different data frame. Likewise, So it goes back to why I want to do this in the first place. I want my own type such that I can define functions for my types even though the backing store is a DataFrame. When I have many types like this, it would be more convenient that I can take two objects and do some dataframe-like operations without having to unwrap them. Thanks for the recommendations. Couple of updates:
It seems to be quite broken at this stage... it makes me think whether I should still go down this path 😅 |
Broadcasting probably should work just by doing:
|
This prototype demonstrates how to implement
AbstractDataFrame
interface. The current implementation allows wrapping a data frame and possibly with additional data in the same struct. The idea came from this comment invenia/KeyedFrames.jl#19 (comment).However, there are a number of unresolved caveats as documented below:
Base.getproperty
(rather than forward) without running into trouble with theparent
functionBase.setproperty!
(rather than forward) to avoid method ambiguity.Base.propertynames
withprivate
argument to make REPL completion work.Base.convert
functionsfindrows
,findrow
,manipulate
, andSubDataFrame
functions.Issue 4 troubles me the most. For the
Base.convert
functions, they seems to be invoked during joins functions andeachcol
. And it calls for converting between a regularDataFrame
and my own type. If I have a type that contains more fields, there is no way to convert from aDataFrame
without filling in dummy information as evident in this line of code (required for passing the test):AbstractWrappedDataFrames.jl/test/runtests.jl
Line 15 in 1fb1e06
Issue 5 is also also quite troublesome because I have to extend some internal
DataFrames.jl
functions. I don't know why they do not takeAbstractDataFrame
type as argument e.g.https://github.com/JuliaData/DataFrames.jl/blob/fb4e184f3b3997da8680668fbf7fcc789811eb18/src/dataframerow/utils.jl#L301-L305
The text was updated successfully, but these errors were encountered: