-
Notifications
You must be signed in to change notification settings - Fork 1
fix: Use singleton PostgresDBClient (Sqlalchemy engine) #321
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
Changes from 19 commits
baf3708
0a335fe
e85f9fb
b2ce4aa
e709932
ad5c1f0
e340876
5ff8620
bb12097
cf2fd49
5b8411e
7906d97
0e3c0a8
9b001fd
dcd8e45
9697231
c22c07d
8e89b00
c17be59
4c44d8d
a960bb4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -42,8 +42,17 @@ class AppConfig(PydanticBaseEnvConfig): | |
# If set, used instead of LITERAL_API_KEY for API | ||
literal_api_key_for_api: str | None = None | ||
|
||
@cached_property | ||
def db_client(self) -> db.PostgresDBClient: | ||
return db.PostgresDBClient() | ||
Comment on lines
+45
to
+47
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This basically creates a singleton PostgresDBClient instance, which holds the Sqlalchemy engine. “the engine is thread safe yes. individual Connection objects are not. we try to describe this at Working with Engines and Connections — SQLAlchemy 2.0 Documentation” |
||
|
||
# def db_session(self) -> db.Session: | ||
# import pdb | ||
# pdb.set_trace() | ||
# return db.PostgresDBClient().get_session() | ||
yoomlam marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
def db_session(self) -> db.Session: | ||
return db.PostgresDBClient().get_session() | ||
return self.db_client.get_session() | ||
Comment on lines
-46
to
+50
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A new session uses an available connection (from the connection pool), so threads (e.g., those created from API calls) will not share a connection. Our pool size is 20 – what happens when max sqlalchemy pool size is reached? Google’s AI states: Requests are queued: Any new requests for a database connection are placed in a queue, waiting for a connection to become available. Timeout begins: SQLAlchemy starts a timeout period (defaulting to 30 seconds, but configurable) to see if a connection is released back into the pool. Connection timeout error: If a connection doesn't become available within the timeout period, an exception (e.g., TimeoutError) is thrown, indicating a connection timeout. SQLAlchemy connection pooling, what are checked out connections? : “If all the connections are simultaneously checked out then you can expect an error (there will be a timeout period during which SQLAlchemy waits to see if a connection gets freed up; this is also configurable).” |
||
|
||
@cached_property | ||
def embedding_model(self) -> EmbeddingModel: | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -22,8 +22,8 @@ def _create_chunks(document=None): | |
] | ||
|
||
|
||
def _format_retrieval_results(retrieval_results): | ||
return [chunk_with_score.chunk for chunk_with_score in retrieval_results] | ||
def _chunk_ids(retrieval_results): | ||
return [chunk_with_score.chunk.id for chunk_with_score in retrieval_results] | ||
|
||
|
||
def test_retrieve__with_empty_filter(app_config, db_session, enable_factory_create): | ||
|
@@ -33,7 +33,7 @@ def test_retrieve__with_empty_filter(app_config, db_session, enable_factory_crea | |
results = retrieve_with_scores( | ||
"Very tiny words.", retrieval_k=2, retrieval_k_min_score=0.0, datasets=[] | ||
) | ||
assert _format_retrieval_results(results) == [short_chunk, medium_chunk] | ||
assert _chunk_ids(results) == [short_chunk.id, medium_chunk.id] | ||
|
||
|
||
def test_retrieve__with_unknown_filter(app_config, db_session, enable_factory_create): | ||
|
@@ -59,7 +59,7 @@ def test_retrieve__with_dataset_filter(app_config, db_session, enable_factory_cr | |
retrieval_k_min_score=0.0, | ||
datasets=["SNAP"], | ||
) | ||
assert _format_retrieval_results(results) == [snap_short_chunk, snap_medium_chunk] | ||
assert _chunk_ids(results) == [snap_short_chunk.id, snap_medium_chunk.id] | ||
|
||
|
||
def test_retrieve__with_other_filters(app_config, db_session, enable_factory_create): | ||
|
@@ -76,7 +76,7 @@ def test_retrieve__with_other_filters(app_config, db_session, enable_factory_cre | |
programs=["SNAP"], | ||
regions=["MI"], | ||
) | ||
assert _format_retrieval_results(results) == [snap_short_chunk, snap_medium_chunk] | ||
assert _chunk_ids(results) == [snap_short_chunk.id, snap_medium_chunk.id] | ||
|
||
|
||
def test_retrieve_with_scores(app_config, db_session, enable_factory_create): | ||
|
@@ -86,7 +86,7 @@ def test_retrieve_with_scores(app_config, db_session, enable_factory_create): | |
results = retrieve_with_scores("Very tiny words.", retrieval_k=2, retrieval_k_min_score=0.0) | ||
|
||
assert len(results) == 2 | ||
assert results[0].chunk == short_chunk | ||
assert results[0].chunk.id == short_chunk.id | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's the reason for these changes? Because the db_session from the test fixture (the second parameter to test_retrieve_with_scores) is different from the db_session generated by retrieve_with_scores? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes. There's some identifier in the chunk instances that is specific to the db_session, so those identifiers are different and cause the assertion to fail. Otherwise the chunks are identical. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Gotcha. I think the identifier here is the literal address in memory: under the hood, SQLAlchemy ensures that if you retrieve the same row back in the same session, it creates only a single instance of the object in memory so you can do things like (psuedocode):
|
||
assert results[0].score == 0.7071067690849304 | ||
assert results[1].chunk == medium_chunk | ||
assert results[1].chunk.id == medium_chunk.id | ||
assert results[1].score == 0.25881901383399963 |
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.
Reverts #317, so it should default back to 4 threads