You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently if the end user has a service that pertains to only one table, they have to specify the table every time that they call From, Insert, etc...
Describe the solution you'd like
The DialectWrapper enables setting the dialect once with Dialect(dialect string) and then calling From, Insert, Update, etc. without needing to specify WithDialect(dialect string). It would be nice to have a similar feature for setting the table once without needing to pass in the table to all of the above listed methods.
One possible solution would be to have a TableWrapper on top of the dialect wrapper. This would require specifying a dialect when you want to specify a table, but I don't think that is an issue. Here is what using it would look like:
Describe alternatives you've considered
It would also be possible to have a table wrapper that doesn't directly rely on the dialect wrapper, but it would make it harder to use both at the same time.
Dialect
postgres
mysql
sqlite3
Additional Context
I can create the PR for this with tests, docs, and examples if it's something that seems like it's worth adding
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently if the end user has a service that pertains to only one table, they have to specify the table every time that they call
From
,Insert
, etc...Describe the solution you'd like
The DialectWrapper enables setting the dialect once with
Dialect(dialect string)
and then callingFrom
,Insert
,Update
, etc. without needing to specifyWithDialect(dialect string)
. It would be nice to have a similar feature for setting the table once without needing to pass in the table to all of the above listed methods.One possible solution would be to have a
TableWrapper
on top of the dialect wrapper. This would require specifying a dialect when you want to specify a table, but I don't think that is an issue. Here is what using it would look like:Here is what the implementation might look like:
Describe alternatives you've considered
It would also be possible to have a table wrapper that doesn't directly rely on the dialect wrapper, but it would make it harder to use both at the same time.
Dialect
Additional Context
I can create the PR for this with tests, docs, and examples if it's something that seems like it's worth adding
The text was updated successfully, but these errors were encountered: