On Jun 9, 2:18 am, Matthew Dowle <[email protected]> wrote: > ... and I added a comment and link back to this thread, to this FR > :https://r-forge.r-project.org/tracker/index.php?func=detail&aid=1006&... > setkey doesn't retain user attributes because it (currently) copies the > data.table, something we'd like to improve anyway. > Matthew > > > > On Wed, 2011-06-08 at 22:34 -0400, Steve Lianoglou wrote: > > Hi, > > > On Wed, Jun 8, 2011 at 7:01 PM, Thell Fowler <[email protected]> wrote: > > > > It looks like custom attributes are lost by a DF to DT creation, and when > > > the key info for a DT is invalidated, altered, etc... I ran into this > > > when trying to attach some attribute info to a table that identifies > > > column groups so that a new global variable or passing another param to > > > functions wouldn't be needed. This worked nicely, until I had need to > > > either modify some data in the table, which invalidates the key... > > > > Was this a design decision? If so, why? > > > Try `as.data.table` for a more "delicate" way to convert a data.frame > > to a data.table. Your attributes will come through to the other side. > > > R> df <- data.frame( id=c(1:5), name= letters[1:5] ) > > R> attr(df, 'testing') <- 'keep me' > > R> dt <- as.data.table(df) > > R> attr(dt, 'testing') > > [1] "keep me" > > > -steve > >
Thank you for the quick replies, for adding this detail to the feature request, and for the as.data.table hint (which I'll be testing today). I guess for now, in instances when a function will invalidate the keys and return the table I'll copy out the specific attributes for column groups, then restore them prior to passing the table back. Sincerely, Thell _______________________________________________ datatable-help mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
