feat(llm): removing all llms to prepare for genoss

[StanGirard]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Checklist before requesting a review

Please delete options that are not relevant.

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented hard-to-understand areas
• I have ideally added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged

Screenshots (if appropriate):

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 31, 2023 1:56pm
quivrapp	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 31, 2023 1:56pm

[github-actions]

LOGAF Level 2 - /home/runner/work/quivr/quivr/backend/core/routes/chat_routes.py

1. The delete_chat_from_db function is catching all exceptions and simply printing them. This is not a good practice as it can make debugging difficult. Instead, consider logging the exceptions and re-throwing them so they can be handled upstream.

try:
    commons["supabase"].table("chat_history").delete().match({"chat_id": chat_id}).execute()
except Exception as e:
    logger.error(e)
    raise

2. The check_user_limit function is using os.getenv to get the MAX_REQUESTS_NUMBER environment variable. This is not a good practice as it can lead to unexpected behavior if the environment variable is not set. Instead, consider using a configuration file or a dedicated configuration management system.

3. The get_chat_details and fetch_user_stats functions are directly interacting with the database. This is not a good practice as it can make the code difficult to test and maintain. Instead, consider using a data access layer or an ORM.

---

LOGAF Level 3 - /home/runner/work/quivr/quivr/backend/core/utils/vectors.py

1. The create_vector function is catching all exceptions and simply logging them. This is not a good practice as it can make debugging difficult. Instead, consider re-throwing the exceptions so they can be handled upstream.

try:
    sids = self.commons["documents_vector_store"].add_documents([doc])
    if sids and len(sids) > 0:
        return sids
except Exception as e:
    logger.error(f"Error creating vector for document {e}")
    raise

2. The process_batch function is directly interacting with the database. This is not a good practice as it can make the code difficult to test and maintain. Instead, consider using a data access layer or an ORM.

---

🚫🐞🗄️

---

Powered by Code Review GPT