Is it possible to not use gorm for database session storage?

[imrenagi]

Hi,

I'm really excited to see adk-go finally released. While it is not too late, can you please reconsider the decision to use gorm for the database storage session?

While GORM is a powerful tool for applications, using it as a hard dependency in a library can introduce several long-term maintainability and usability challenges for its consumers. My suggestion is to consider an approach that decouples the library's core logic from a specific database implementation like GORM.

Cheers!

[appleboy]

See the reference PR: #177. In Progress.

[imrenagi]

@appleboy what do you mean by in progress? that PR you referred to is already merged. what progress are you referring to?

[dpasiukevich]

@imrenagi thanks for the feedback!

Could you clarify what do you mean by "hard dependency in a library" here?
ADK core library is decoupled, it only requires session.Service interface implementation. Where gorm is one of the implementations.

There's also VertexAI session service WIP #235. This provides lightweight persistent session storage.

[imrenagi]

Hi @dpasiukevich sorry for the confusion.

I was just wondering why it isn't going with standard library like database/sql or probabaly sqlx for the database. I had used gorm back then, but was thinking there were too many "magic" and "hack" that we must do, rather than just doing it with plain sql query.

Thanks!

[shanipribadi]

https://pkg.go.dev/google.golang.org/adk@v0.1.0/session#Service
session.Service is there for people to implement their persistent session store with whatever they want.
and you wouldn't need to even download the gorm/sql dependency if you don't import from session/database.
@imrenagi

The session/database package is there to provide a ready-to-use Session Store for people quickly.
Using gorm is nice that it allows a single implementation to work with multiple databases out of the box (MySQL, Postgressl, SQLite, GaussDB, Spanner, TiDB, and perhaps others).
Having this out-of-the-box SessionStore accepting a database/sql.DB or sqlx.DB directly will not work, because the implementation will need to be different depending on the actual database being used (different type support, SQL dialects, etc).
Hence the use of an ORM for this package.

For production usage you can always implement your own session.Service.

Unfortunately right now it's not really usable yet because of one simple reason @dpasiukevich ,
https://github.com/google/adk-go/blob/v0.1.0/session/database/service.go#L32

type databaseService struct {
	db *gorm.DB
}

the gorm.DB and the various table structs are private, and not exposed by any method, meaning you can't even execute the db.AutoMigrate(...) method to setup the database tables.

the tests work right now because it has access to the private fields
https://github.com/google/adk-go/blob/v0.1.0/session/database/service_test.go#L966

[imrenagi]

Thanks @shanipribadi . Yep i can agree that using ORM most of the time will work for the sake of simplicity in supporting many databases.

Thanks for the discussion!

[dpasiukevich]

@shanipribadi that's a good summary, thanks!

Moreover, the session service functional requirements are quite basic: simple read/writes, some wrapped in a transaction. I don't expect GORM to be problematic here in the long run. Even as a plan B it's possible to add "db-specific" providers (e.g. postgres) which will use database/sql with minimum dependencies.

And, as I've mentioned, we're working to add support for VertexAI session service, which is a free saas solution. I'd even say this would be the best option to start with.

[dpasiukevich]

Regarding exposing gorm DB type in the database provider (or some subset of it), this definitely makes sense and we'd follow up on this.

Thanks!

[dpasiukevich]

@shanipribadi hi, we've added the AutoMigrate func helper #241 to allow init tables.

As for exposing gorm.DB and/or go structs defining the tables, I'd like to keep them internal as implementation detail for now. And with all communication with data done properly via session.Service methods.

Exposing gorm.DB and the table types for data manipulation IMO should be a last resort.

Let us know WDYT, thanks!