VEuPathDB/vdi-service

Summary **AND** Description to App DB

Opened this issue · 9 comments

Problems

Presently:

  1. We are only writing the description to the App db control table for a given dataset.
  2. The current description column in the App db is limited to 4k characters.

Proposal

  1. Change the App DB schema: (by @steve-fischer-200)
    a. change the type of the description column to CLOB through some series of changes
    b. add a new summary column typed as VARCHAR2(4000)
  2. Change the REST API to reject summaries greater than 4k characters in length.
  3. Change the APP DB lib to insert into the new column
  4. Update the client to disallow summaries > 4k in length. - may require @dmfalke

Concerns

  • Existing summaries greater than 4k length?

Followup

  • Get the summaries for currently installed datasets into the app dbs, VDI won't know to do this on its own.

@dmfalke, if you want to tackle the client change, it isn't blocked by anything on the backend, that can go out ahead of time or whenever.

The only issue with it happening after the service change is the UX for when a user gets a 4xx error for the summary being too long.

Is the length of description unbounded?

Yes, description is already unbounded in VDI, and is going to be changed to CLOB in the App DB.

Maybe we could have some sanity check limit in place though? 🤔 Like, is there a use case for more than 1M of text for example?

Maybe we could have some sanity check limit in place though? 🤔 Like, is there a use case for more than 1M of text for example?

We should probably only do this if we know we want to 🙂. Maybe something to consider as user datasets become more central.

PR for VDI based changes #335

@steve-fischer-200 did we update the summaries/descriptions for existing datasets in the app dbs? I remember some work being done on this but I don't remember if it was finished.

@dmfalke have the client changes been made for this already?

@dmfalke have the client changes been made for this already?

Nope. I have a draft PR that I haven't looked at in a while. I can resurrect it, if needed.

Nope. I have a draft PR that I haven't looked at in a while. I can resurrect it, if needed.

IDK what the priority on it is/was, I'm pretty sure the backend change is done and in on this already and was wondering if this ticket should be closed.

Maybe the client handling of the response 422 error is good enough?