Page History

...

1. Open discussion
   1. Scholars: GraphQL and REST API
      1. Huda: Had considered a single API for VIVO with GraphQL or other implementations under the hood, so technologies or implementations could change without changing the API itself
      2. Ralph: GraphQL actually talking to REST API
      3. Don: Historical reasons: REST API part of TAMU's work with Angular. 
   2. Don: TDB loading is slow
      1. Brian: Haven't encountered a situation where TDB is as slow as SDB. Use SPARQL API.  Sometimes service available can remotely turn off inferencing/indexing.  Plain SPARQL update.  TDB usually better than SDB in this context
         1. May be related to how threads are managed
      2. Don: With RDF delta patch work - if listener is waiting for changes, if that portion could be put on another server, that may relieve resources for the main VIVO app
   3. Huda: Issue (also on email list) around how indexing plays into profile page load.  When information is updated, the first time the profile comes up it takes a long time
      1. Brian: Is she using multiple languages and if there are several? Noticed slow down recently that large publication lists in conjunction with large publication lists and on SDB, slow down possible because of filtering for desired language if operating against a much larger result set from SDB query
      2. Indexing process separate and not much related to the profile page, so it shouldn't be indexing that slows down the profile page
      3. Don: Custom faux properties that use OPTIONAL instead of UNION
      4. Ralph: Sometimes power settings on desktops can mess things up
      5. Huda: Will also suggest coming onto the development call and perhaps sharing screen/participating to help with debugging and/or troubleshooting
   4. Brian: Could be different ways of handling languages (as well as other areas) if were to architect from the ground up in the future
   5. Don: How does threading work with SPARQL update API?
      1. Brian: Not sure if additional threads are spun up. Each request made is own independent thread.  Separate threads talking to Jena persistence layer, and the Jena layer would be responsible for dealing with concurrent requests. 
      2. Don: Pondering what other options there are for sharding TDB store, etc. to load a lot more data quickly
   6. Benjamin: How safe to backup TDB without shutting down Tomcat? If transaction occurring while directory is being copied, there's a chance it could be corrupted
      1. Have cron job for backing that up nightly and ok so far
      2. Brian: could first check to see if lock file in TDB directory - if write lock exists, then wait until lock file disappears and then risk pretty lowly of copying at that point
      3. Don: Harvester issue - had to put in db close statements, operated on TDB - write locks gone in directory but database still thought it was open.  Set up branch in VIVO Community harvester and have PR from maint-rel-.1.11 into develop branch.
         1. Could we have a read only TDB?
         2. Brian: could write it so that only read only queries would be active (in the RDF service layer).  somewhere in startup listeners that set up two different models
2. In-review tickets 

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1732

   2. 
      

      Expand
      Jira server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

      
      

...