Broken datatype displays.

[Ben Wagner]

Hello XNAT gurus,

  XNAT 1.9.3 and I'm having difficulty with "Failed to create search results" when trying to load the default tab for many custom datatypes.  Error in SQL.log is always the same:

org.postgresql.util.PSQLException: ERROR: column "sub_project_identifier_XXX" does not exist

XXXX is the project identifier.  sub_project_identifier_XXX seems to be an auto generated field.  Sometimes the log shows this possibly helpful tidbit (but I expect not):

Hint: Perhaps you meant to reference the column "search.mr_project_identifier_XXX".

I've attached one of the bad schemas.  This is affecting multiple shemas...some that haven't been touch in several years and XNAT versions.  

What is odd is I can access the data through the Brows >> Data  menu and through some existing custom searches in projects.

Any ideas would be appreciated.

Ben

[Timothy Olsen]

I think I'd need to see the search xml that the page is using for the failed listings (available in Dev Tools).  If it's easier to hop on a call and look at it together you could grab some time on my calendar here: Calendly

Tim

Timothy R Olsen 

Founder, President

 t...@xnatworks.io

 xnatworks.io | Find us on LinkedIn! 

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/xnat_discussion/83616925-2e2f-40c6-8ca4-f7fde25a254bn%40googlegroups.com.

[Ben Wagner]

Hi Tim,

  I think I'm attaching what you want.  Also I've included the SQL statement that's failing.  I'm decent at SQL, but this computer generated statement a bit much for me.

Ben

To view this discussion visit https://groups.google.com/d/msgid/xnat_discussion/CAOAXJbaZ%3DOKybjaTYjtHn9bu3a8%3D1SUuUNK44-mn%3D1u_5c6_Yg%40mail.gmail.com.

[Ben Wagner]

Hi Tim/XNAT,

  I was wondering if you had a chance to try and reproduce this error?

Thanks,

Ben

[Timothy Olsen]

Apologies, Ben.  I haven't gotten back to this one.  

I was curious if maybe these were customized listings?  Or are they the 'auto-generated' ones that come on a project report?  Did you do a Save As on the ones that are broken?

Tim

Timothy R Olsen 

Founder, President

 t...@xnatworks.io

 xnatworks.io | Find us on LinkedIn! 

To view this discussion visit https://groups.google.com/d/msgid/xnat_discussion/CADVL1QyVB4Wzn6zeybSZce6v8Tornx5cTkO%2BW6DyAiDOu%3DrL9Q%40mail.gmail.com.

[Ben Wagner]

Hi Tim,

  Most have display documents (customized listings?).  Mainly these are xmllint --format of the build display as the build ones are ugly to look at.   Several contain simple additional fields (field references, not SQL).  I tried one without display docs for a fair trial and still get "Failed to create search results" and "org.postgresql.util.PSQLException: ERROR: column "sub_project_identifier_long" does not exist" in the SQL.log.  There are no saved/stored searches on the datatype trialled.

Ben

To view this discussion visit https://groups.google.com/d/msgid/xnat_discussion/CAOAXJbbs9vM_0s2y0zVibOfqX_pDeRDzmzD0x6X2aboLESvvuQ%40mail.gmail.com.

[Ben Wagner]

Hi Tim and all,

  I'm circling round back to this error.  I just installed a new XNAT and 2 datatypes. Uploaded a little data and the first time I go to the datatype tab I get the org.postgresql.util.PSQLException: ERROR: column "sub_project_identifier_testbed" does not exist.  I'd really hoped a clean installation would clear this up, but no such luck.  It's been a few months.  Were you ever able to track this down/reproduce?

Ben

[Ben Wagner]

Well, with a little AI help this was suggested..and it worked!  FYI...

  - Replace:
      - element_name="xnat:subjectData" id="SUB_PROJECT_IDENTIFIER"
  - With:
      - element_name="xnat:subjectData" id="SUBJECT_LABEL"

To view this discussion visit https://groups.google.com/d/msgid/xnat_discussion/2caae3a0-5500-4137-9e0a-750bdb8aea04n%40googlegroups.com.

[Timothy Olsen]

Yes, that is a good fix for your case. It will even improve performance too.  But it wont work out well if you use project sharing   That change hard codes the listing to always use the root project label for the subject.  So, if you are sharing AND relabeling your subjects, then this wouldn't be ideal.  Another option would just be to remove that column entirely in that scenario.  Sorry I didn't think of that sooner.  AI for the win.  I'll note that in the pending 1.10 release, you'll be able to configure the columns in the default listings IN the application (no restarts or code change necessary).

The bug points to a deeper issue I'll need to resolve.  My final round of search engine improvements is supposed to be in development this summer.  That would definitely resolve this issue (and alot of other search flakiness too).  But, it probably won't be released until end of Q3 at best, Q4 more likely.  So, I'm glad you have a workable stop gap.

To view this discussion visit https://groups.google.com/d/msgid/xnat_discussion/CADVL1QxsaKGQnzZ%2B1wiOh%3DG2bFAf09UQrNd52%3DF4JT-NXVrbCA%40mail.gmail.com.

[Ben Wagner]

Hi Tim,

Thanks for the update.  I'll keep an eye out for the end of year release and hopefully be able to revert these changes.  Fingers crossed.

Ben