-
Notifications
You must be signed in to change notification settings - Fork 15.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
community[minor]: Add SQL storage implementation #22207
community[minor]: Add SQL storage implementation #22207
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
cbc83bb
to
2671786
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically ready to merge, we just need to resolve a few issues with the sql alchemy schema
…ins/agents/docs (langchain-ai#16168) Revamp SQL use cases docs. In the process update SQL chains and agents.
…corator (langchain-ai#16295) Adjusted `deprecate` decorator to make sure decorated async functions are still recognized as "coroutinefunction" by `inspect`. Before change, functions such as `LLMChain.acall` which are decorated as deprecated are not recognized as coroutine functions. After the change, they are recognized: ```python import inspect from langchain import LLMChain # Is false before change but true after. inspect.iscoroutinefunction(LLMChain.acall) ```
- **Description:** add milvus multitenancy doc, it is an example for this [pr](langchain-ai#15740) . - **Issue:** No, - **Dependencies:** No, - **Twitter handle:** No Signed-off-by: ChengZi <[email protected]>
beb3278
to
2612714
Compare
@eyurtsev Please, can you check this other Add async mode for pgvector ? it has been blocked for 3 weeks because "@eyurtsev requested changes", but I can't find the changes I want, so I can't validate them |
libs/community/pyproject.toml
Outdated
@@ -31,6 +31,7 @@ optional = true | |||
pytest = "^7.3.0" | |||
pytest-cov = "^4.1.0" | |||
pytest-dotenv = "^0.5.2" | |||
aiosqlite = "^0.19.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI @pprados aiosqlite should be in extended testing only not in this test group -- I'll move it to the appropriate place
this is reserved for testing infrastructure (pytest, pytest-cov, etc.)
There are a few things that don't belong here (e.g., duckdb-engine, lark), but we'll remove those as well at some point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK it's already in extended testing, so we should be all set 🤞
@@ -0,0 +1,186 @@ | |||
"""Implement integration tests for Redis storage.""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd recommend removing integration tests since they duplicate the content of unit tests.
unit tests will run on CI right now under the extended tests run.
At the moment, integration tests are not run as part of CI (since they typically require access to external resources that are not set up)
…elf query retriever (#22678) The fact that we outsourced pgvector to another project has an unintended effect. The mapping dictionary found by `_get_builtin_translator()` cannot recognize the new version of pgvector because it comes from another package. `SelfQueryRetriever` no longer knows `PGVector`. I propose to fix this by creating a global dictionary that can be populated by various database implementations. Thus, importing `langchain_postgres` will allow the registration of the `PGvector` mapping. But for the moment I'm just adding a lazy import Furthermore, the implementation of _get_builtin_translator() reconstructs the BUILTIN_TRANSLATORS variable with each invocation, which is not very efficient. A global map would be an optimization. - **Twitter handle:** pprados @eyurtsev, can you review this PR? And unlock the PR [Add async mode for pgvector](langchain-ai/langchain-postgres#32) and PR [community[minor]: Add SQL storage implementation](#22207)? Are you in favour of a global dictionary-based implementation of Translator?
…elf query retriever (langchain-ai#22678) The fact that we outsourced pgvector to another project has an unintended effect. The mapping dictionary found by `_get_builtin_translator()` cannot recognize the new version of pgvector because it comes from another package. `SelfQueryRetriever` no longer knows `PGVector`. I propose to fix this by creating a global dictionary that can be populated by various database implementations. Thus, importing `langchain_postgres` will allow the registration of the `PGvector` mapping. But for the moment I'm just adding a lazy import Furthermore, the implementation of _get_builtin_translator() reconstructs the BUILTIN_TRANSLATORS variable with each invocation, which is not very efficient. A global map would be an optimization. - **Twitter handle:** pprados @eyurtsev, can you review this PR? And unlock the PR [Add async mode for pgvector](langchain-ai/langchain-postgres#32) and PR [community[minor]: Add SQL storage implementation](langchain-ai#22207)? Are you in favour of a global dictionary-based implementation of Translator?
Hello @eyurtsev - package: langchain-comminity - **Description**: Add SQL implementation for docstore. A new implementation, in line with my other PR ([async PGVector](langchain-ai/langchain-postgres#32), [SQLChatMessageMemory](#22065)) - Twitter handler: pprados --------- Signed-off-by: ChengZi <[email protected]> Co-authored-by: Bagatur <[email protected]> Co-authored-by: Piotr Mardziel <[email protected]> Co-authored-by: ChengZi <[email protected]> Co-authored-by: Eugene Yurtsev <[email protected]>
…elf query retriever (#22678) The fact that we outsourced pgvector to another project has an unintended effect. The mapping dictionary found by `_get_builtin_translator()` cannot recognize the new version of pgvector because it comes from another package. `SelfQueryRetriever` no longer knows `PGVector`. I propose to fix this by creating a global dictionary that can be populated by various database implementations. Thus, importing `langchain_postgres` will allow the registration of the `PGvector` mapping. But for the moment I'm just adding a lazy import Furthermore, the implementation of _get_builtin_translator() reconstructs the BUILTIN_TRANSLATORS variable with each invocation, which is not very efficient. A global map would be an optimization. - **Twitter handle:** pprados @eyurtsev, can you review this PR? And unlock the PR [Add async mode for pgvector](langchain-ai/langchain-postgres#32) and PR [community[minor]: Add SQL storage implementation](#22207)? Are you in favour of a global dictionary-based implementation of Translator?
xfailing some sql tests that do not currently work on sqlalchemy v1 #22207 was very much not sqlalchemy v1 compatible. Moving forward, implementations should be compatible with both to pass CI
xfailing some sql tests that do not currently work on sqlalchemy v1 langchain-ai#22207 was very much not sqlalchemy v1 compatible. Moving forward, implementations should be compatible with both to pass CI
Hello @eyurtsev