trying to force my way through anyways to be able ...
# squarelibraries
n
trying to force my way through anyways to be able to report the issues..
v
Just want to thank you for all the issues you've been reporting. They've been super helpful 🙏
n
something else i have not reported or really know how to report.. having the plugin enabled in IDEA kinda kills performance and memory but i am not sure how to properly collect info about that that is the nsapshot version ofc
v
Is it related to the latest version (1.4.2)? Because there is an issue about that here
n
it is on 1.5.0-SNAPSHOT
v
Can you try downgrading to 1.4.1 and see if that helps?
n
but it could very well be the same issue
i will do that and see if it improves performance.. i assume that will cause some of the postgres syntax that was fixed in 1.5.0-SNPASHOT to show up as error in ide IDE again ?
btw i have currently 3 submodules that set up sqldelight
or maybe 4 ? trying to keep my code modular led to the modules asking
:core
for a database connection (which is all the same db, just different schemas)
v
There wasn't anything added to the PostgreSQL grammar since 1.4.1 (see the CHANGELOG) so everything should work the same in terms of syntax
n
what about the fixes of stuff like
SERIAL
? that showed up as errors in the IDE before iirc
v
I don't believe the fix for
SERIAL
is in SQLDelight yet, is it?
From the looks of it SQLDelight is on sql-psi v0.3.6 and the
SERIAL
fix was added after that
To make sure we're talking about the same thing, are you talking about the addition of https://github.com/AlecStrong/sql-psi/pull/140 or https://github.com/AlecStrong/sql-psi/pull/160? Because the former should be in SQLDelight 1.4.1, but the latter isn't in any version of SQLDelight (not even the SNAPSHOT)
n
iirc you forgot some plumbing for 140 and fixed it in https://github.com/cashapp/sqldelight/pull/1884 so i guess most of it was in 1.4.1 but not working until this
as just forking the dialect to test some changes is much more manageable than the whole of sqldelight
also possibly easier for users to report issues to the right repository directly.. bu that might just be wishful thinking
v
Ah yeah I forgot about that PR. Yeah that is included in 1.4.1
+1 for https://github.com/AlecStrong/sql-psi/issues/155, it'll hopefully make the PostgreSQL grammar less dependent on SQLite in SQLDelight
also possibly easier for users to report issues to the right repository directly.. bu that might just be wishful thinking
Not sure I get what you mean here. From what I understand we'd still have two repos: sql-psi and sqldelight. In the future sql-psi would just be a multi-module repo with a module per dialect
n
i mean that is more clear to users that there IS a sql-psi there because they have to configure it here.. this was news to me initially and only one link in the docs points there.. and i would assume some oissues that are really grammar related come into the sqldelight repo
i wonder if it would be possible to pick the dialect not va extension but instead as a dependency configuration.. i think if gradle lets this order of operations happen.. maybe it would even be possible to register dependency configurations for each database added in the extension.. that would be neat since it could tie in better with other tooling to manage dependencies.. eg. refreshVersions or such then again this block of code
dialect = "com.cashapp.sql.dialects:sqlite-3.24:1.0.0"
does look like you might just shove it into a dependency in the plugin..
v
Yep there's an open issue in SQLDelight to flesh out the contributing guide lines more so this is all a bit clearer. It took me a while to get up and running, and this was definitely the first roadblock that I hit. https://github.com/cashapp/sqldelight/issues/1878
Yep each module with a dialect would then be a gradle dependency