-
Notifications
You must be signed in to change notification settings - Fork 11
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
Access to column names for given repo in Repo instance #4
Comments
Motivating example: def insertIgnoreDuplicates(insert: ProjectInsert)(using DbCon): Int =
sql"""
INSERT OR IGNORE INTO projects (organization, repository, logo)
VALUES (${insert.organization}, ${insert.repository}, ${insert.logo})
""".update.run() could very well be: def insertIgnoreDuplicates(insert: ProjectInsert)(using DbCon): Int =
sql"""
INSERT OR IGNORE INTO projects $insertColumns
VALUES ($insertParameters)
""".update.run() under the assumption that in scope of |
That's a great idea, I will definitely accept a PR. I also like the idea of adding such methods to ImmutableRepo. |
This could be closed but it also can track the work necessary to actually include |
Sounds good :) |
Hi,
I'm looking into how one can leverage work done by Magnum's reflection to help write future-proof queries in Repo subclasses. One thing that would be massively helpful would be if selectable and insertable columns (
eElemNamesSql
andecElemNamesSql
inRepoDefaults
macros respectively) would be available on eitherRepoDefaults
(one can alwayssummon[RepoDefaults[...]]
) or even better, onImmutableRepo
(selectable columns) andRepo
(insertable columns). I imagine you could return them in a custom collection type (a wrapper over Vector maybe?) that has an overriddentoString()
so that it can format them correctly as in SqliteDbType:You could expose that logic on DbType subtypes and then use it by catching proper DbType in macro just as you do now in
RepoDefaults
and passing it to the custom collection instance to format columns on interpolation. This would allow user to filter out columns on demand while still providing correct set of columns driven by the structure of actual scala case classes and not via flaky query strings.What do you think? Would you accept a PR with such functionality?
The text was updated successfully, but these errors were encountered: