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!

Hi @Evgeny Shvarov 

Thank you for asking. Please check if the respective OpenAI/Cohere API Keys have been added in the 'API Keys' section on the settings page.


If the API Keys are present and the error persists, ensure that all fields are filled out when adding the instance in the Settings page and an active instance is chosen. Also, verify that all fields in the connectors flow are filled.

I hope this should resolve the issue. If not, please let me know.

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!

Hey Zacchaeus & team! Congratulations on this great implementation. I'm sure quite a lot of applications can be built on top of this.

I have a question. If my understanding is right, I believe you are using FHIR APIs to take any action. Curious about how the right API is chosen based on the user command. I ask because a few months back we worked on FHIR: AI and OpenAPI chain project where the massive size of the OpenAPI documentation of FHIR led to slow response times. Your project seems faster in comparison. I'd be interested to learn more about how was the performance optimized.