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

Let the user know there could've been some problems with the indexing #1083

Merged
merged 10 commits into from
Mar 5, 2021

Conversation

scarlehoff
Copy link
Member

@scarlehoff scarlehoff commented Feb 5, 2021

Related to the discussion yesterday.

Before discussing how to best re-index or re-upload I think it is important that at least the code doesn't give the wrong message, i.e., if don't see any errors in your terminal it should really mean there were no errors.

So this just checks whether the fit was indexed.

This is a prototype but before adding the to-dos below (which are mostly cosmetic) I would like whether you think it is worth it or not @Zaharid @scarrazza

To do:
-Control the wait time
-Add a command line argument to skip the wait
-Follow the structure of the rest of the class instead of just having a chunk of code there in the middle.

While this doesn't truly solve #1079 it makes it less of a problem.

@scarlehoff scarlehoff marked this pull request as draft February 5, 2021 08:44
@scarlehoff scarlehoff changed the title Tell the user if there are indexing problems Let the user know there could've been some problems with the indexing Feb 5, 2021
@scarlehoff scarlehoff linked an issue Feb 5, 2021 that may be closed by this pull request
@scarlehoff
Copy link
Member Author

scarlehoff commented Feb 22, 2021

As luck would have it, all the fits and pdfs I've uploaded to test this were indexed so it's hard to know whether it would work if they weren't. Other than that this is ready for review.

As a side note, I think the pdf and fit uploader classes could be further merged.

@scarlehoff scarlehoff marked this pull request as ready for review February 22, 2021 14:48
return True
return False

def _check_existence(self, fit_name):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this done again?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because I felt it was ugly to have basically the same code copied twice for pdfs and fits but at the same time I didn't want to remove the duplicated code that already existed.

@Zaharid
Copy link
Contributor

Zaharid commented Feb 22, 2021

As a side note, I think the pdf and fit uploader classes could be further merged.

Possibly. I would be happy if that was done.

@Zaharid
Copy link
Contributor

Zaharid commented Feb 22, 2021

Just to add a note the remote fits are cached so one should not expect them to be updated by repeated calls. This matters because I was about to suggest waiting for a shorter period of time and then retrying, which may still be a good idea but has to be done carefully.

@functools.lru_cache()

@scarlehoff
Copy link
Member Author

Possibly. I would be happy if that was done.

Ok, I'll do this since I'm already here.

@scarlehoff
Copy link
Member Author

Ok, done. The second commit (cb19c0b) might be a bit more controversial of course.

On the bright side I got an "index failure" (and it was true, I uploaded again and this time it worked) so I was able to test that as well.

validphys2/src/validphys/uploadutils.py Outdated Show resolved Hide resolved
validphys2/src/validphys/uploadutils.py Outdated Show resolved Hide resolved
validphys2/src/validphys/uploadutils.py Outdated Show resolved Hide resolved
@Zaharid
Copy link
Contributor

Zaharid commented Feb 23, 2021

If we are doing OOP here we could as well do it all the way. Rather than having a weird inheritance chain of PDFUploader(FitUploader) we should have an intermediate class ArchiveUploader that encapsulated the common behaviour.

@scarlehoff
Copy link
Member Author

Yes, that's fine. Although in this case the pdf does work as a subclass of fit. I'll do it tomorrow if I have time.

@scarlehoff
Copy link
Member Author

I've used your ArchiveUploader name for this. Ready for Review.

validphys2/src/validphys/uploadutils.py Outdated Show resolved Hide resolved
validphys2/src/validphys/uploadutils.py Outdated Show resolved Hide resolved
raise UploadError

def compress(self, output_path):
log.info("Checking whether %s was correctly uploaded...", resource_name)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why you don't use an f-string here and in one other place below? Personally I tend to find them a bit easier to read

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because has bullied me for years.
In reality I guess if you are ever bottle-necked by the writing of the logging then you have bigger problems than that... tbh I don't mind either way.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that you should really use this format in logging right? pylint complains if you don't, something about lazy formatting so I guess this gets resolved later than the f-string?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's the case. But tbh I don't think "compiling" a string will ever be a bottleneck of any kind...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure sure, I was just saying I think we should follow the "rules"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the more valid concern is that logging has the very theoretical capability of doing things with the args other than printing them. But it is also unlikely to matter.

validphys2/src/validphys/uploadutils.py Outdated Show resolved Hide resolved
validphys2/src/validphys/uploadutils.py Outdated Show resolved Hide resolved
validphys2/src/validphys/uploadutils.py Outdated Show resolved Hide resolved
validphys2/src/validphys/uploadutils.py Outdated Show resolved Hide resolved
validphys2/src/validphys/uploadutils.py Outdated Show resolved Hide resolved
validphys2/src/validphys/uploadutils.py Outdated Show resolved Hide resolved
scarlehoff and others added 2 commits March 3, 2021 11:55
Co-authored-by: Cameron Voisey <32741139+voisey@users.noreply.github.com>
@voisey
Copy link
Contributor

voisey commented Mar 4, 2021

I'm not sure how best to check whether you get the right behaviour when it doesn't index properly...? I've uploaded a test fit which worked fine, so that's not broken at least...

@scarlehoff
Copy link
Member Author

I don't know. I got one that failed and actually failed but other than luck I'm not sure how to do it without xluttering the server

@voisey
Copy link
Contributor

voisey commented Mar 4, 2021

Shall we just merge then?

@Zaharid
Copy link
Contributor

Zaharid commented Mar 5, 2021

Tested and looks good to me, thanks!

@Zaharid Zaharid merged commit ef475a4 into master Mar 5, 2021
@Zaharid Zaharid deleted the check_fit_indexed branch March 5, 2021 17:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

The server doesn't index
4 participants