DatabaseSessionService class: set a more explicit way to decide the schema

[Istorn]

The class DatabaseSessionService permits to set up the connection to the DB via DB URL and add different flags via kwargs.

From my perspective it would be great to permit the user setting the schema as explicit parameter.

• Reason: DB schema is one of the core elements when it comes to interact with the DB itself
• Use case: PostgreSQL database, but it could be related to any other relational DB kind of
• Proposal:

As is:

session_service = DatabaseSessionService(db_url, connect_args={"options": "-c search_path=NAME_OF_MY_SCHEMA"})

To Be:

session_service = DatabaseSessionService(db_url, schema="NAME_OF_MYSCHEMA")

[dylan-apex]

Duplicate/Related to #2115

[jeffreyrubi]

hi @Istorn , i'm interested to work on this feature. Left some of the thought and would like to see if this can support your case:

2 changes to be made for it:

Change 1: Add optional arg "engine" to init() of the DatabaseSessionService.
Benefits: Scalable to many agents system because different sessions (of different agent) can share the same connection pool to the same SQL engine. The response time will also be much faster when db connections are reused.

Change 2:For every session manipulation method, keep it within a context which: (a) create the schema if it does not exist. (b) utilize the schema translate map to make operation under the give schema.
Benefits: Ensure the designated schema is effective in every operation to allow recycling of db connections.

This enhancement is very critical to enable the SessionService to support different enterprise cases where agents need to work on separate schemas with proper data isolation. Let me know if it sounds fine. I could submit a PR accordingly.

[Istorn]

Hi @jeffreyrubi wanna join the forces together?

I understand your concerns, what if we keep a default option in case of none custom ones are being provided?

[jeffreyrubi]

Sure. Happy to join force.

For default option, that's what i mean the engine should be optional. Backward compatibility is important. I'm expecting the change will not impact any current implementation.

[dylan-apex]

While working on this, can you update the adk.cli.fast_api.get_fast_api_app() to also accept a database engine?

[klateefa]

@Istorn Thanks for reporting!
We are currently reviewing your feature request,Its under review
Thanks for your patience.