Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Introduce the new DDL #957
Introduce the new DDL #957
Changes from 48 commits
c9887c9
e7a3526
e9df325
c2e84eb
a8f85ca
dc3d7e3
08c7214
221976a
55a5a80
51b3f79
e43c76a
f0c1cc6
df885f3
a324e21
3ac84f9
e11acd7
0bb2e70
9244d33
d6b8d2f
0ce0eb5
71c1501
0c52e1a
9b7de0f
640c27b
7a451d3
82fb25a
cfb27bc
c3adb74
147c02f
cd292ea
e80c8ce
724dcdb
a98682d
507fbc3
0f7accd
0836745
e511517
bbaff1f
2a38182
971c7d5
72abf29
457ae2c
9d63d40
f84ad0b
7d5ccc3
6570474
8a0675f
422efa6
8e0cc87
2c928b2
54f05ba
0b12f7b
f00e181
019f26c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to add:
or
teal_data_module
object created byteal_data_module()
(the latter with link)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't quite get the idea behind
hashables
but it looks to be an unique identifier of the input data (e.g. you do calculate hash on env with data tables in it). Here you are extracting server function body and calculate hashes on this. Please note that the same server function might return different object (vide:runif()
but more realisticaly here: module with file upload). I don't think this is what we expect in the next step.(The same mistake below where we call
hashables$data$get_code()
)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hashables are for different reason. Hashes are not used for reproducibility purposes, and they are not returned in the R code. This single hash is needed to identify an app. At this moment it is used as "id" for
filter
argument, to check whether filter is applied to the same app. This means:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we update the comment a few lines up to be more descriptive?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - that would be great for a person from the outside.
So I was wrong with my interpretation but the problem stays the same. The way how you calculate the hash now identify whether the data loading module is the same. You can have multiple apps with the same data loading module.
I have other objections for other cases of that if but it's going beyond the scope of this PR so will keep quiet here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If app1 and app2 use the same data module, then app2 can use a filter snapshot created in app1.
Note that
modules
is also hashed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So then few more comments:
Just to clarify as I wanted to understand this better.
IMO those two sentences conflicting with each other. If app1 and app2 uses the same data module but different analysis modules then the has won't be identical (as we include modules as well) and we cannot re-use the filter. Am I missing something here?
Also: are you sure?
Let's leave 1. and assume same data module and same analysis modules. Let's assume the following:
So the hash here will be the same and are you sure that we can re-apply filters from APP1 to APP2? Am I right here?
I have the impression that this becomes imperfect as we introduce the concept of teal_data_module in which the same module can return different datasets. I am just trying to find a good test case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ad 1. Sorry for the confusing phrasing. I did mean that in order to use an uploaded snapshot, it must come from an app that used the same data (module) and modules. You are right, those are not exactly different apps. Which is the point ot the hash.
Ad 2. For the data module to return different (or even differently named) datasets it would have to have either a) different server code or b) the same server code that modifies data (see the new vignette for examples), where different data is supplied. The former seems safe enough. The latter, not necessarily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AD 1. Thanks. Now it's more clear.
AD 2. I am actually thinking about yet another possibility of dynamically named object -> things like:
x <- foo_named_list_of_df(input$foo, input$bar); list2env(x, env = current_env())
. The server code is the same but it can return different things based on user inputs. This essentially means that our identifier mechanism based on hashing of server fun body is imperfect (also taking into account use case b) you mentioned).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right.
So in the particular case you describe snapshot compatibility is upheld. Data names may be different but the data objects themselves are the same.(wrong, datanames are used inteal_slice
s 🤦) If you decide to change column names, then you're in trouble.The question is, is this a valid use case? Are dataset names (let alone variable names) ever left up to the app user? We don't even provide for the app user to be able to modify variable labels (yet).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is. To me, that's one of the greatest things about teal-data-module concept. It essentially unlocks total flexibility of data names, column names, column types and everything else. We even say in the docs that (the only) limitation is that the returned object has to be of
teal_data
class. How you achieve that - it's up to the module developer. And that's great.This feature does not fit well with our
conceptimplementation of filters re-applicability which I am highlighting here. Now I don't know if we should invest in finding appropriate way of implement this this (here) or revisit this as a whole.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stop()
convert tocheckmate
to have better consistency of error handling(also same in the block above but you haven't touched this)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are you sure?
if yes - is this the only place where we use this function?
if yes - shall we remove it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, too early for this. I was testing something and pushed by mistake. Reverting.
FYI we will remove
resolve_delay
fromui
functions anyway soon.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool. Yes - I am expecting this to be removed but was surprised this happened so fast :P