search

jeff-zucker / solid-file-client

A Javascript library for creating and managing files and folders in Solid data stores
MIT License
55 stars 18 forks source link

v1.0.0 Testing #52

Closed Otto-AA closed 4 years ago

Otto-AA commented 5 years ago

An issue to discuss testing and keep track of testing for the v1.0.0 release

TODOs:

If you think that something is done, just add a comment. If something is missing, just add it.

jeff-zucker commented 5 years ago

I'll leave the logging decisions up to you. What you suggest sounds good.

On Sat, Jun 22, 2019 at 10:02 AM A_A notifications@github.com wrote:

I would start adding basic logging now with the debug https://www.npmjs.com/package/debug module. It works in node and browsers and provides the ability to log to different channels. The channels can be enabled separately, so for instance I could only enable "solid-file-client:fetch" or everything from our package with "solid-file-client:*". Something I am not entirely happy about is, that it doesn't has a log-level setting (e.g. debug/info/error/...), but I guess using different channels is sufficient. So I think it would be a good choice. Are you ok with this logger, or would you prefer another one?

For now I would only add a "solid-file-client:fetch" channel which outputs all requests and their response status code, for instance 200 - GET https://example.org/file.ext. This seems useful for debugging as we would quickly know which requests fail, so I'd like to do this now. Later on we can add logging for other methods too.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeff-zucker/solid-file-client/issues/52?email_source=notifications&email_token=AKVJCJACC5D6YJGH5OSEJBDP3ZLMBA5CNFSM4HXOKHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYKNNZQ#issuecomment-504682214, or mute the thread https://github.com/notifications/unsubscribe-auth/AKVJCJEZZCOJNI7RGTTT3VTP3ZLMBANCNFSM4HXOKHIQ .

jeff-zucker commented 5 years ago

There are some bugs in the way localStorage,js is handling readFolder. I would advise sticking with file:// and https:// until I get it fixed, probably tomorrow morning.

Otto-AA commented 5 years ago

What would you think about disabling all tests for now which test unfinished methods? It is a bit irritating that every time I run the tests I see several high-level-xyz tests fail, but as I have no clue if any of these tests should actually pass at this stage, I have to ignore the errors for now. If we only enable those tests which should pass at this stage, it would be easy to see if something has been broken by a change (instead of guessing it was already broken before the change). Also would allow us to add Travis CI now, so we can double check with every commit/PR if something has been broken. I don't think that it would slow us down.

jeff-zucker commented 5 years ago

Do anything you want with the jest tests. As I said, I have to have tests that work in all three environments and I can't do that in jest so haven't touched the jest tests in days. The crud test is somewhat redundant anyway as yoiu point out it is mostly just calling methods with defaults.

On Sun, Jun 23, 2019 at 10:40 PM A_A notifications@github.com wrote:

What would you think about disabling all tests for now which test unfinished methods? It is a bit irritating that every time I run the tests I see several high-level-xyz tests fail, but as I have no clue if any of these tests should actually pass at this stage, I have to ignore the errors for now. If we only enable those tests which should pass at this stage, it would be easy to see if something has been broken by a change (instead of guessing it was already broken before the change). Also would allow us to add Travis CI now, so we can double check with every commit/PR if something has been broken. I don't think that it would slow us down.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeff-zucker/solid-file-client/issues/52?email_source=notifications&email_token=AKVJCJH7VBN4HDUMCPC6N2TP4BM3TA5CNFSM4HXOKHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYL2DHA#issuecomment-504865180, or mute the thread https://github.com/notifications/unsubscribe-auth/AKVJCJBPHYOEWUZUZELFACTP4BM3TANCNFSM4HXOKHIQ .

jeff-zucker commented 5 years ago

I've disabled the high-level-crud test for now and added the crud-node test I have been using.

jeff-zucker commented 5 years ago

@bourgeoa if you have time and interest, I am wondering if you would like to take on two specific tasks as we move towards a release of v1.0.0.

1) track changes that are backwards incompatible with the current solid-file-client; I'm trying to make notes in the code as I go; but when we are closer to release, it would be great if you could double-check

2) test in the browser; the tests/crud-node file should work in a browser with minor modifications and/or feel free to invent tests. I am thinking of manually run tests.

jeff-zucker commented 5 years ago

@bourgeoa you may have seen the forum posting that v0.5.2 does not compile. My opinion is, we have too much work on v1.0.0 to spend much effort on previous versions so simplest would be to just remove everything after 0.4.9 from npm. But you're the one who has done the work, so I'll leave the decision to you.

bourgeoa commented 5 years ago

Quite ok for point 1. and 2.

I shall not invest time on v0.5.2 For information the compile error seems to relate to npm request and angular. ( in private message with @sofimrtn)

The 0.5.x versions being older than 72h they cannot be deleted. It seems we can only try to publish a 0.5.3 === 0.4.9

jeff-zucker commented 5 years ago

I just pushed my version of crud-node which works for me. Let me know if that fixes your problem.

On Thu, Oct 3, 2019 at 2:31 PM Alain Bourgeois notifications@github.com wrote:

@jeff-zucker https://github.com/jeff-zucker I do not succeed to launch the node tests/crud-node : I suppose i am doing something wrong. I used to launch it

SOLID_IDP=https://solid.community/ SOLID_USERNAME=bourgeoa SOLID_PASSWORD=janv31 TEST_PREFIX=https:// TEST_BASE_URL= https://bourgeoa.solid.community/public/tests/ node tests/crud-node module.js:540 throw err; ^

Error: Cannot find module '../' at Function.Module._resolveFilename (module.js:538:15) at Function.Module._load (module.js:468:25) at Module.require (module.js:587:17) at require (internal/module.js:11:18) at Object. (/volume1/homes/admin/github/jeff-zucker/solid-file-client/tests/crud-node:30:19)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeff-zucker/solid-file-client/issues/52?email_source=notifications&email_token=AKVJCJAWJAJK5TJ5I7CZNWDQMZQDRA5CNFSM4HXOKHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAJVGWA#issuecomment-538137432, or mute the thread https://github.com/notifications/unsubscribe-auth/AKVJCJHKKHZR5Q6N3AQBQVDQMZQDRANCNFSM4HXOKHIQ .

bourgeoa commented 5 years ago

In fact I forgot to build. Sorry

Le ven. 4 oct. 2019 à 18:40, Jeff Zucker notifications@github.com a écrit :

I just pushed my version of crud-node which works for me. Let me know if that fixes your problem.

On Thu, Oct 3, 2019 at 2:31 PM Alain Bourgeois notifications@github.com wrote:

@jeff-zucker https://github.com/jeff-zucker I do not succeed to launch the node tests/crud-node : I suppose i am doing something wrong. I used to launch it

SOLID_IDP=https://solid.community/ SOLID_USERNAME=bourgeoa SOLID_PASSWORD=janv31 TEST_PREFIX=https:// TEST_BASE_URL= https://bourgeoa.solid.community/public/tests/ node tests/crud-node module.js:540 throw err; ^

Error: Cannot find module '../' at Function.Module._resolveFilename (module.js:538:15) at Function.Module._load (module.js:468:25) at Module.require (module.js:587:17) at require (internal/module.js:11:18) at Object.

(/volume1/homes/admin/github/jeff-zucker/solid-file-client/tests/crud-node:30:19)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/jeff-zucker/solid-file-client/issues/52?email_source=notifications&email_token=AKVJCJAWJAJK5TJ5I7CZNWDQMZQDRA5CNFSM4HXOKHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAJVGWA#issuecomment-538137432 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AKVJCJHKKHZR5Q6N3AQBQVDQMZQDRANCNFSM4HXOKHIQ

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeff-zucker/solid-file-client/issues/52?email_source=notifications&email_token=AAQ5TZX74QOHB2BOKYBCXRLQM5WWDA5CNFSM4HXOKHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAMHDGQ#issuecomment-538472858, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQ5TZSWGVVWI5BFA3VWNC3QM5WWDANCNFSM4HXOKHIQ .

bourgeoa commented 5 years ago

I am working to test solid-file-client v1.0.0 with solid-ide and I come to what I think is a bug in solidApi.readFolder I have a folder /test and a file /test/test.txt The type should be text/plain it appears to be ["plain#Resource","ldp#Resource"] (below is a display from solid-ide including content)

folder{"type":"folder","name":"test","parent":"https://alain.bourgeoa.ga/","url":"https://alain.bourgeoa.ga/test/","folders":[],"files":[{"url":"https://alain.bourgeoa.ga/test/test.txt","type":["plain#Resource","ldp#Resource"],"modified":"2019-10-06T21:12:04Z","mtime":"1570396324.644","size":"4","itemType":"Resource","name":"test.txt","parent":"https://alain.bourgeoa.ga/test/"}],"content":"@prefix : <#>.\n@prefix test: <>.\n@prefix ldp: http://www.w3.org/ns/ldp#.\n@prefix terms: http://purl.org/dc/terms/.\n@prefix XML: http://www.w3.org/2001/XMLSchema#.\n@prefix st: http://www.w3.org/ns/posix/stat#.\n@prefix pl: http://www.w3.org/ns/iana/media-types/text/plain#.\n\ntest:\n a ldp:BasicContainer, ldp:Container;\n terms:modified \"2019-10-06T21:45:12Z\"^^XML:dateTime;\n ldp:contains ;\n st:mtime 1570398312.964;\n st:size 4096.\n\n a pl:Resource, ldp:Resource;\n terms:modified \"2019-10-06T21:12:04Z\"^^XML:dateTime;\n st:mtime 1570396324.644;\n st:size 4.\n"}

jeff-zucker commented 5 years ago

Thanks for spotting that. I know where to fix it. I will change and commit it soon.

On Sun, Oct 6, 2019 at 5:02 PM Alain Bourgeois notifications@github.com wrote:

I am working to test solid-file-client v1.0.0 with solid-ide and I come to what I think is a bug in solidApi.readFolder I have a folder /test and a file /test/test.txt The type should be text/plain it appears to be ["plain#Resource","ldp#Resource"] (below is a display from solid-ide including content)

folder{"type":"folder","name":"test","parent":" https://alain.bourgeoa.ga/","url":"https://alain.bourgeoa.ga/test/","folders":[],"files":[{"url":"https://alain.bourgeoa.ga/test/test.txt","type":["plain#Resource","ldp#Resource"],"modified":"2019-10-06T21:12:04Z","mtime":"1570396324.644","size":"4","itemType":"Resource","name":"test.txt","parent":"https://alain.bourgeoa.ga/test/"}],"content":"@prefix : <#>.\n@prefix test: <>.\n@prefix ldp: http://www.w3.org/ns/ldp# .\n@prefix terms: http://purl.org/dc/terms/.\n@prefix XML: http://www.w3.org/2001/XMLSchema#.\n@prefix st: http://www.w3.org/ns/posix/stat#.\n@prefix pl: http://www.w3.org/ns/iana/media-types/text/plain#.\n\ntest:\n a ldp:BasicContainer, ldp:Container;\n terms:modified "2019-10-06T21:45:12Z"^^XML:dateTime;\n ldp:contains ;\n st:mtime 1570398312.964;\n st:size 4096.\n\n a pl:Resource, ldp:Resource;\n terms:modified "2019-10-06T21:12:04Z"^^XML:dateTime;\n st:mtime 1570396324.644;\n st:size 4.\n"}

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeff-zucker/solid-file-client/issues/52?email_source=notifications&email_token=AKVJCJDOHMTAIIOI6HBEATLQNJ4ABA5CNFSM4HXOKHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAOXPZA#issuecomment-538802148, or mute the thread https://github.com/notifications/unsubscribe-auth/AKVJCJHMJTI6HXQHNMDYOQDQNJ4ABANCNFSM4HXOKHIQ .

bourgeoa commented 4 years ago

@Otto-AA I am working to practically use v1.0.0 (with solid-ide). I already made a PR #76 I have implemented copy/delete recursively and I am encountering a difficulty to use the return which is an area of object Response :

Would it not be better to return true or false and only the list of errors/URI - or [object Response] ? Is it possible to delete/copy recursively if there are no errors ? or at least to make it a default option ?

What do you think ?

Otto-AA commented 4 years ago

@bourgeoa SolidApi.fetch always calls _assertResponseOk which will throw when response.ok is not true. So if an API method is unsuccessful, it should throw (ie reject the Promise), else it will resolve.

Here are two examples, one using async/await and one plain Promises (out of my head, may have little errors):

try {
  const responses = await api.deleteFolderRecursively(url)
  console.log('Successfully deleted folder')
} catch (err) {
  console.error('Error while deleting folder')
}
api.deleteFolderRecursively(url)
  .then(responses => {
    console.log('Successfully deleted folder')
  })
  .catch(err => console.error('Error while deleting folder'))

Would it not be better to return true or false and only the list of errors/URI - or [object Response] ?

Currently all (not 100% sure about that) api methods in SolidApi work that way, so I'd prefer it to be consistent. It also gives the user the ability to e.g. log all urls of the deleted items on success.

Is it possible to delete/copy recursively if there are no errors ? or at least to make it a default option ?

Sorry, but I don't think I understand what you mean here. When you call deleteFolderRecursively it tries to delete it recursively and stop on the first error. Hence, if there are no errors it deletes the folder + contents.

bourgeoa commented 4 years ago

@Otto-AA thanks for your help I was simply missing to check for err @jeff-zucker

I'd like to come back to some of my questions with copyFolder

I have made a test folder (folder3/) containing a few files and a bad content test.json Folder and folder contents are copied except the bad folder3/test.json (returns a 400 Bad content error)

Nota : PUT is not actually working for .json files (no body), but I reported the issue and made a PR : https://github.com/solid/node-solid-server/pull/1346 (I applied the PR to my server for the test)

bourgeoa commented 4 years ago

And now with deleteFolderRecursively

@Otto-AA you write that the function stops at the first encountered error.

  1. Should it not be preferable to delete all except the ones in error. I have come to this https://stackoverflow.com/questions/31424561/wait-until-all-promises-complete-even-if-some-rejected It is proposed a reflect concept/function which allow to execute all fulfilled promises and have a list of all rejected ones. So you are not in an in between situation where some promises are fulfilled until one is rejected and then you stop.

  2. an other approach would be - not do anything if there is an error - I thought it was Promise.all, but I seem to have misunderstand that. Anyway it is nice to have the list of rejected

bourgeoa commented 4 years ago

@jeff-zucker @Otto-AA A few changes to make { withLinks: true } functional for delete/copy recursively. See PR #78. Tested on https://www.bourgeoa.ga/solid-ide-v1

Otto-AA commented 4 years ago

why is there any folder content copied : I was expecting that with a Promise.all returning an error no promise would be executed (doing a dry run) ?

If I add an second bad content .json file (both files are not copied). But I only catch the first error. I can see both of them in the console.log

A little explanation on Promise.all: Promise.all(promises) only takes care of waiting until (i) all promises are resolved or (ii) one of them rejects. It isn't responsible for calling the functions (copyFile and copyFolder in our case). We actually do this ourselves while creating the const promises (here). In these lines it already starts to copy the folder contents.

Doing a try run seems rather impossible to me. I don't know how we could check, if the copy process will be successful. We could try if fetching works for all files, but that still doesn't guarantee that writing it to the other location will also work properly. Or if something is missing or malformed in the process.

Should it not be preferable to delete all except the ones in error. I have come to this https://stackoverflow.com/questions/31424561/wait-until-all-promises-complete-even-if-some-rejected It is proposed a reflect concept/function which allow to execute all fulfilled promises and have a list of all rejected ones. So you are not in an in between situation where some promises are fulfilled until one is rejected and then you stop.

an other approach would be - not do anything if there is an error - I thought it was Promise.all, but I seem to have misunderstand that. Anyway it is nice to have the list of rejected

As explained above, all promises in deleteFolderContents (see here) are executed. Promise.all may reject earlier, but that doesn't "uncall" the deletion requests. This means that deleteFolderContents will delete everything possible, even if something fails.

In deleteFolderRecursivley the situation is slightly differently. There we use await this.deleteFolderContents(url) to make sure that the folder is empty. Only if this succeeds we continue deleting the folder (if we don't do this we would get the 409 Confilct response). So here it makes sense not to try to delete on an error.

Together this means, that deleteFolderRecursively will delete everything possible. If a file/folder fails to be deleted, it won't delete the parent container too. All other contents will still be deleted.

Regarding the list of rejected promises, I think that it's a nice idea. It should work if you replace all Promise.all with this promiseAllWithErrors method:

// Similar to the proposed Promise.allSettled method (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/allSettled)
function allSettled(promises) {
  const reflectedPromises = promises.map(promise => {
    return promise
      .then(value => { return { status: 'fulfilled', value }})
        .catch(reason => { return { status: 'rejected', reason }})
  })
  return Promise.all(reflectedPromises)
}

// Specific to our use case
async function promiseAllWithErrors(promises) {
  const res = await allSettled(promises)
  const errors = res.filter(({ status }) => status === 'rejected').map(({ reason }) => reason)
  if (errors.length)
    throw errors
  return res.filter(({ status }) => status === 'fulfilled').map(({ value }) => value)
}

It is based on the Promise.allSettled method which should be available in the future (but is still in the draft). It behaves similar to Promise.all except that it waits for all errors.

Otto-AA commented 4 years ago

When I check the response I find response.url being folder3/ . Which is the parent of the file in error (ok using POST). So I tried replacing (in copyfolder only) the fileCreate with POST with a fileCreate with PUT and I have the same err 400 but now the url is folder3/test.json which is much easier to use for debugging. Will that be acceptable ? I have not seen anything against in solid/specification (or is there an other way may be to enrich response with slug)

Yes, I think it would make more sense to switch to PUT for copyFile. We've already had the discussion here. I think it would be best to add a putFile method, which also uses the WriteOptions. And copyFile should use putFile then.

For creating folders we have to stick to POST though (the spec doesn't allow PUTting a container).

Otto-AA commented 4 years ago

Could one of you two, @bourgeoa @jeff-zucker enable travis for this project? I think you just need to sign in with github on this page and then enable it here: https://travis-ci.org/jeff-zucker/solid-file-client/

Here is also a really short guide on getting started if this doesn't work: https://travis-ci.org/jeff-zucker/solid-file-client/

bourgeoa commented 4 years ago

Sorry not me no admin rights for me

Le sam. 30 nov. 2019 à 09:30, A_A notifications@github.com a écrit :

Could one of you two, @bourgeoa https://github.com/bourgeoa @jeff-zucker https://github.com/jeff-zucker enable travis for this project? I think you just need to sign in with github on this page and then enable it here: https://travis-ci.org/jeff-zucker/solid-file-client/

Here is also a really short guide on getting started if this doesn't work: https://travis-ci.org/jeff-zucker/solid-file-client/

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeff-zucker/solid-file-client/issues/52?email_source=notifications&email_token=AAQ5TZR7UJRK3WPVUBK7A3LQWIQA3A5CNFSM4HXOKHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFP4ZDY#issuecomment-559926415, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQ5TZWH2ER6AXV2KRAHG3LQWIQA3ANCNFSM4HXOKHIQ .

Otto-AA commented 4 years ago

Oh ok, no problem. Then @jeff-zucker needs to do this

jeff-zucker commented 4 years ago

I can give both of you admin rights if you'd like, though it may be cleaner to have only one of us doing that. It's up to you, if you want admin rights, just ask.

Do we really want to add travis at this point? There are so many changes. Wouldn't it avoid complexity to hold off on travis until most things are done?

On Sat, Nov 30, 2019 at 12:30 AM A_A notifications@github.com wrote:

Could one of you two, @bourgeoa https://github.com/bourgeoa @jeff-zucker https://github.com/jeff-zucker enable travis for this project? I think you just need to sign in with github on this page and then enable it here: https://travis-ci.org/jeff-zucker/solid-file-client/

Here is also a really short guide on getting started if this doesn't work: https://travis-ci.org/jeff-zucker/solid-file-client/

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeff-zucker/solid-file-client/issues/52?email_source=notifications&email_token=AKVJCJF7ORPHQXJK7DOOMYDQWIQA3A5CNFSM4HXOKHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFP4ZDY#issuecomment-559926415, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKVJCJBEXGU3MPAR55U5LLDQWIQA3ANCNFSM4HXOKHIQ .

Otto-AA commented 4 years ago

Do we really want to add travis at this point? There are so many changes. Wouldn't it avoid complexity to hold off on travis until most things are done?

I think that the things which are being tested currently (mostly in SolidApi) are rather stable already. Having travis set up would give us feedback if a change introduces errors in those methods. We still don't need to get all tests passing before pushing/merging something, but it could be a useful feedback...? That's my view on it. But it's not necessary, I can also run npm test locally every time I pull something.

jeff-zucker commented 4 years ago

I'm going to hold off on Travis until I am more caught up on all the changes. Too much to think about all at once.

On Wed, Dec 4, 2019 at 1:43 PM A_A notifications@github.com wrote:

Do we really want to add travis at this point? There are so many changes. Wouldn't it avoid complexity to hold off on travis until most things are done?

I think that the things which are being tested currently (mostly in SolidApi) are rather stable already. Having travis set up would give us feedback if a change introduces errors in those methods. We still don't need to get all tests passing before pushing/merging something, but it could be a useful feedback...? That's my view on it. But it's not necessary, I can also run npm test locally every time I pull something.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeff-zucker/solid-file-client/issues/52?email_source=notifications&email_token=AKVJCJDK575IIWRRO7NNIMLQXAP7HA5CNFSM4HXOKHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF6TA2Y#issuecomment-561852523, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKVJCJCD6SVCUAYSW72D3LTQXAP7HANCNFSM4HXOKHIQ .

jeff-zucker commented 4 years ago

Version 1.0.0. is now released, closing background issues.