As seen in the video at 29:16 and a few other timestamps, I'm encountering a ...iris.dbapi._DBAPI.OperationalError: AccessDenied error (sometimes) when making DB API calls. This issue arises randomly during the middle of a session, making it difficult to provide steps to replicate.

I don't think this error is limited to vector embedding related SQL query execution; I have also encountered it while executing other SQL statements, such as fetching all tables by schema name.

Has anyone else faced a similar issue? If so, could you please share your solution or guide me on how to raise this as an issue?

Thank you!

Yeah, that's a very fair point. Leveraging OpenWebUI would help scale up to bringing in more possibilities that IRIS could do with comparatively lower efforts than native UI stack. I wish I had known this before, would have been a different play on scaling up capabilities.

Hi @Luc Morningstar! Thank you for asking.

I am executing SQL queries for the interactions with IRIS DB. Here are few examples on how it's used

1. iris-ai-studio/backend/list_tables.py In this file you could see a query that's being called when I wanted to fetch all the table names in the IRIS DB instance with 'SQL_User' schema

   SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'SQLUser

2. iris-ai-studio/backend/chat_llama.py Here, `IRISVectorStore` function from llama-iris library being used, which does execute the SQL query needed to do operations on storing/retrieving of vector embeddings into/from IRIS DB. An example from that:

   CREATE OR REPLACE FUNCTION llamaindex_l2_distance(v1 VARBINARY, v2 VARBINARY)
   RETURNS NUMERIC(0,16)
   LANGUAGE OBJECTSCRIPT
   {
       set dims = $listlength(v1)
       set distance = 0
       for i=1:1:dims {
           set diff = $list(v1, i) - $list(v2, i)
           set distance = distance + (diff * diff)
       }
   
       quit $zsqr(distance)
   }

The same `IRISVectorStore` function being used all across for loading and retrieval purposes (data_loader.py, chat_llama.py, query_llama.py, similarity_llama.py, reco_llama.py). Since this library encapsulates the needs on interaction with the IRIS DB, I didn't replicate the same functioning. 

In my previous post I got inputs on leveraging IoP (Interoperability on Python) for achieving similar outcome through a more leaner way. I'm learning that and exploring if it could be incorporated along with the current functioning. 

I hope this answers your query. Please let know if you may have any more questions!

Thanks for sharing this @Richard Burrell . So helpful and relevant ones!

liteLLM sounds like a perfect need for a studio concept like this, which could help user explore possibilities from various different vendors. And it's nice they have a hosted UI for configuration too. That was actually an limitation for me while trying to scale up for more models, having a clear distinction of available Vendors, Models along with it's configuration wasn't easy to put through on a lean UI. OpenWebUI looks interesting too, but it would be more on the retrieval side alone right?

Thank you, @Guillaume Rongier 

This sounds interesting. Previously, I explored a few interoperability adapters for a different use case. But this example of performing vector operations through a lighter model seems exciting. I did go for llama-index for its connectors mainly, but I believe going through the interoperability route would be leaner, especially for some retrieval use cases, that I could think in terms of no. of operations.

I would definitely love to learn more, and this has sparked my excitement about having this capability in the playground. Let me look into it further!

Hi Irina! Thanks for bringing this to my attention. I've added my response!

Thank you, Irina!