Show an error message that the Hecke orbit is not available if the db record is missing.

[sehlen]

No description provided.

[sehlen]

This is part of a fix for #1217

[AndrewVSutherland]

Reviewing now.

[AndrewVSutherland]

So does what we want for ModularForm/GL2/Q/holomorphic/23/9/22/, i.e. it notes that the Hecke orbit 23.9.22.a is not available.

But it does something different for the similar situation for ModularForm/GL2/Q/holomorphic/11/11/10/, where 11.11.10.b is present but 11.11.10.a is missing (and there are dozens more like this). It says that the whole space is missing (whereas the current code on www.lmfdb.org displays the space gets 11.11.10.a wrong). If we are going to throw out the whole space 11.11.10, then we should disable the link on 11.11 (i.e. grey it out).

To see the difference, compare:

http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/11/11/10/
http://127.0.0.1:37777/ModularForm/GL2/Q/holomorphic/11/11/10/

versus

http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/23/9/22/
http://127.0.0.1:37777/ModularForm/GL2/Q/holomorphic/23/9/22/

[sehlen]

It doesn’t do that for me…

I get for ModularForm/GL2/Q/holomorphic/11/11/10/ that 11.11.10.a is not clickable and it shows the message as it should.
I don’t understand how it could possibly do anything else (look at the code).
How did you try this? Could it be a caching issue?

(I am directly connected to warwick for mongo and am running the website locally on my laptop.)

Note that the underlying issue is a data issue.
It is hard to track that back for me because Fredrik did the computations but it is probably not very hard for me to try to recompute missing guys.

On May 7, 2016, at 17:23, AndrewVSutherland notifications@github.com wrote:

So does what we want for ModularForm/GL2/Q/holomorphic/23/9/22/, i.e. it notes that the Hecke orbit 23.9.22.a is not available.

But it does something different for the similar situation for ModularForm/GL2/Q/holomorphic/11/11/10/, where 11.11.10.b is present but 11.11.10.a is missing (and there are dozens more like this). It says that the whole space is missing (whereas the current code on www.lmfdb.org http://www.lmfdb.org/ displays the space gets 11.11.10.a wrong). If we are going to throw out the whole space 11.11.10, then we should disable the link on 11.11 (i.e. grey it out).

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub #1219 (comment)

[sehlen]

Sorry, I was stupid so I had to update this again to make sure the number fields really are not displayed.

[JohnCremona]

I am checking (after the 3rd commit!)

[fredstro]

And of course the whole 'rational coefficients ' business is because the
lmfdb_label for the number field fails to update so the default 1.1.1.1 is
used..
Fredrik

On Sat, 7 May 2016 17:11 Stephan Ehlen, notifications@github.com wrote:

Sorry, I was stupid so I had to update this again to make sure the number
fields really are not displayed.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1219 (comment)

[sehlen]

@fredstro Yes, I know but this is not really an issue here. The dimension was shown to be 0 and this is the default in this case. If for whatever reason this happens (that there's no db record) then we should show a reasonable error message and only block navigation to the problematic records, not to the whole space. That's what I did now.

[JohnCremona]

I tried about a dozen of the problem cases in Drew's list and all don't crash, instead displaying (in some cases many times) the message "This Hecke orbit is unfortunately not available." properly in the table.

I think that is what this was supposed to fix until the missing data is inserted. So I will merge this now but we should not close the issue until the missing data is in there.

[fredstro]

@sehlen i see this reply got into the wrong thread.... I'm sorry it's a
bumpy road where we are driving now....
We should probably look over the general strategy and make sure that we
dint assign default values when we can't get stuff from the database.

On Sat, 7 May 2016 17:16 Stephan Ehlen, notifications@github.com wrote:

@fredstro https://github.com/fredstro Yes, I know but this is not
really an issue here. The dimension was shown to be 0 and this is the
default in this case. If for whatever reason this happens (that there's no
db record) then we should show a reasonable error message and only block
navigation to the problematic records, not to the whole space. That's what
I did now.

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#1219 (comment)

[sehlen]

@fredstro It took me a while to realize you are actually referring to a bumpy road you're driving on and didn't mean this as a metaphor for the lmfdb project ;-)

[sehlen]

Thanks @JohnCremona for reviewing this.

[fredstro]

@sehlen it was intentional :)

On Sat, 7 May 2016 17:32 Stephan Ehlen, notifications@github.com wrote:

Thanks @JohnCremona https://github.com/JohnCremona for reviewing this.

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#1219 (comment)

[JohnCremona]

I took the bumpy road to be metaphorical too!

[AndrewVSutherland]

:)

On May 7, 2016, at 12:32 PM, Stephan Ehlen notifications@github.com wrote:

@fredstro It took me a while to realize you are actually referring to a bumpy road you're driving on and didn't mean this as a metaphor for the lmfdb project ;-)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub