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

Allow locking or protecting a data.table from any modifications #1086

Open
ClaytonJY opened this issue Mar 18, 2015 · 7 comments
Open

Allow locking or protecting a data.table from any modifications #1086

ClaytonJY opened this issue Mar 18, 2015 · 7 comments
Labels
feature request top request One of our most-requested issues

Comments

@ClaytonJY
Copy link

This issue arose from Stack Overflow here: https://stackoverflow.com/questions/29085334/lock-or-protect-a-data-table-in-r

I would like to be able to make a data.table unmodifiable. In the comments below my question, two changes to the data.table package are proposed by other users:

  1. make modify-by-reference functions respect the lockBinding() function
  2. make modify-by-reference functions respect a "read.only" attribute. Jan Gorecki has already implemented this for [.data.table here: https://github.com/jangorecki/data.table/tree/read.only

Either solution would work for me.

@jangorecki
Copy link
Member

maybe we can use drop param?

# in-place assign by reference
dt[, a := b]
dt[, a := b, drop=TRUE]
# copy `a` column
dt[, a := b, drop=FALSE]

This way we can not modify our initial data.table, and have the results materialized as copy. And there is drop finally useful.

@eantonya
Copy link
Contributor

I think OP wants to prevent semi-accidental modifies, not intentional ones. To achieve what the above drop example does, I'd just use copy now and imo that's easier/more understandable.

@jangorecki
Copy link
Member

Good point.
I'm working on package which injects read.only branch functionality into data.table, so user can stick to data.table and prevent not intentional modification. Still it can be improved for [, := ] detection as it now copies the object even if you are not using :=. But one extra copy is a cheap trade-off for locking DT.

@jangorecki
Copy link
Member

@ClaytonJY I just pushed that functionality into separate package. It allows you to stick to data.table master. jangorecki/dtq will inject same functionality as mentioned data.table branch.
It is heavy in dev but read.only feature is stable. If you want to use just read.only feature you might want to turn off the main feature of package by options("dtq.log" = FALSE).

@aryoda
Copy link

aryoda commented Jul 9, 2017

Any news about the state of locking data.tables? I ran into the same requirement, see
https://stackoverflow.com/questions/44995065/r-how-to-make-a-data-table-read-only-without-copying-it-e-g-for-data-validat

Update: The package dtq by @jangorecki implements this feature by implicitly copying the data.table, but I would like to avoid making a copy and prefer getting an explicit error so that the developer can recognize the problem (violation of read only data).

Is it possible to add this feature into the data.table package?

THX!

PS: Code snippet in the dtq package (injected into the data.table):

# read.only mode
    if(isTRUE(attr(x,"read.only",TRUE))){
      x <- copy(x)
      setattr(x,"read.only",NULL)
}

Source: https://github.com/jangorecki/dtq/blob/master/R/zzz.R

@aryoda
Copy link

aryoda commented Jul 10, 2017

This is a (partial?) duplicate of the older #778

@jangorecki jangorecki changed the title [Request] Allow locking or protecting a data.table from any modifications Allow locking or protecting a data.table from any modifications Apr 3, 2020
@MichaelChirico
Copy link
Member

As noted in #778, I'm not sure it's possible to use the lockBinding() mechanism directly -- it's simply too hard to tell in general when an object is locked using the public APIs R provides (please CMIIW).

However, we could still fulfill this issue with a new function like lockTable() that has a familiar name to lockBinding() but actually works by setting an attribute that assign() can read & respond to.

This would also get around the back-compatibility flaws of the lockBinding() approach mentioned in #778.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request top request One of our most-requested issues
Projects
None yet
Development

No branches or pull requests

5 participants