Repository navigation
caching (server dependent) #397
Description
How about prefixing the caching directories with the inversed URL of the server? Many problems have occurred because we are confusing cache items from the test server with live cache items. This could easily be fixed
In the java connector this is fixed by prefixing the cache directory with the inversed server url, e.g. .openml/cache/org/openml/www/datasets, etc
Metadata
Metadata
Assignees
Labels
No labels
Activity
mfeurer commentedon Feb 12, 2018
Great idea!
mfeurer commentedon Mar 19, 2018
After rethinking this a bit, could you please comment on this @janvanrijn ?
The different toolboxes should store the same information (i.e. xml files). If they don't, that might be a bug.
janvanrijn commentedon Mar 19, 2018
Can you elaborate? I don't see why that is a strict requirement.
Ideally, yes, but this requires a big effort.
I wouldn't mind making several changes to the java lib if that unifies matters, would be best to do when we're all together (including representative of mlr)
mfeurer commentedon Mar 19, 2018
It isn't, we just decided to that once upon a time. Still, how can the files differ if only xml files are stored?
janvanrijn commentedon Mar 19, 2018
it's about the directory structure. This one is different in java (I actually prefer the Python directory structure). Also, the pickled files can of course not be red in java and R.
However, let's discuss that in a different topic. The issue that is raised in this one is that 99% of our (the devs) cache problems come from using cache across servers (test and production). This is something that can be solved fairly easy (in fact, I already did so in the Java lib).
mfeurer commentedon Mar 20, 2018
Sorry for getting side-tracked and talking about something completely different. We should actually check back with the R guys whether they think this is a good idea (I definitely do!) and then also update the docs/Wiki.
@giuseppec @berndbischl
giuseppec commentedon Mar 20, 2018
Good point, I also ran into that problem several times...
berndbischl commentedon Mar 21, 2018
i think if we plan and communicate that change properly, we can easily do that
mfeurer commentedon Mar 21, 2018
As long as we use the solution proposed by @janvanrijn the proposed and current caching structure won't interfere with each other so we would gradually update the different packages?
mfeurer commentedon Apr 4, 2018
I just added a PR in #432.
Merge branch 'develop' into fix/#397