https://kotlinlang.org logo
Join Slack
Powered by
but outside of sqlite i think most use `deriveSche...
# squarelibraries
a
but outside of sqlite i think most use 
deriveSchemaFromMigrations
s
I was actually looking for something like this 🙂 Thanks
p
That deriving makes so much more sense than anything else, I'd like to see this more promoted as the suggested configuration
💯 1
a
we could default it to true for mysql/postgres
but weird to base that on dialect
probably better to just promote more in the doc like you say
p
But why do most use it outside of sqlite and not for sqlite?
a
on mobile devices people are still doing fresh installs and need fresh dbs, thats never the case in a distributed database where theres one (or many) that are always runnings
we could use it for sqlite by just installing a fresh db by running every migration in order (including version 0)
which I think does make sense, but we’re all just used to what SQLiteOpenHelper told us to do
p
We use it for sqlite exactly like described
a
yea
does it work well?
p
Yep
a
i would also like to do that
p
I mean the generated code is kind of inefficient but that doesn’t hurt at all
a
yea i agree
and its less code to write
p
Its funny when you read the generated code especially for onCreate. Its like: create x, alter x, alter x, alter x, drop x
The big advantage is that it’s really consistent between migrations so you can not really end up with unpredictable inconsistent states like: This app migrated from x to y and the other from a to y and now they are slightly distinct.
a
thats a very good point
we do intend on building migration squashing stuff since thats pretty normal for server dev too
p
It’s also a reason why I really dislike rooms default with 
create table if not exists
. I really want it to crash instead of later playing detective and find out which versions migrated how
a
does all the IDE stuff still work
I’ve never tried any of this for SQLite lol
p
You mean with the ide plugin? I don’t use that
a
yea the ide plugin
p
Today’s my free day but I can try tomorrow if you’re interested
a
I’d recommend trying it regardless, its pretty life changing
like you dont have to recompile to generate the sqldelight code
that alone i think is worth it
p
It caused and delays on sync iirc; that’s why we disabled it
a
interesting
p
a
that was making sync longer? it should just be a separate thing
p
I can’t say for sure, its at least a year ago that I tried the last time and I didn’t properly measure it
a
there was like a two week stretch where that was like leaking memory so maybe its better now
it should be fine now, the message is still there but it should be a separate process
p
I’ll give it a try tomorrow
s
So about what you guys were talking about earlier - so I had actually enabled 
deriveSchemaFromMigrations
already in the database, I had just forgotten about it. Drawing more attention to this in the docs is a good idea, especially for server development. It’s fantastic. Speaking about docs, I currently jump around between the platforms, trying to understand the full scope of something. There might be a better way to divide the documentation. i.e. I read about migrations on a few pages before I was able to understand naming, where sqlite really doesn’t care about anything except for numbers in the file name, which allows me to make my migrations name compatible with flyway. I still am not confident in whether or not sqldelight supports semversion numbers (i.,e. 2.1 as flyway recommends in their documentation), but I assume not.
a
i dont think it does, but its worth double checking and documenting
s
i.e. what I was referencing earlier - here’s the documentation for mysql, technically what I care about - https://cashapp.github.io/sqldelight/jvm_mysql/migrations/ but I wasn’t able to get a clear picture what was going on until I looked at the Android documentation: https://cashapp.github.io/sqldelight/android_sqlite/migrations/
a
yea that info is more here https://cashapp.github.io/sqldelight/jvm_mysql/#migration-schema for non-sqlite but i agree we should have more info on migrations there
s
I’m trying to figure out what in the documentation clued me into the fact that the position of the number in the sqm file didn’t matter.
v
like you dont have to recompile to generate the sqldelight code
Alec what do you mean with that? I've also stopped using the Gradle Plugin since the moment I installed it (back in the 0.x & 1.0.x days) Android Studio just went noticeably slower
a
you mean the intellij plugin?
it also generates the sqldelight code when you make file edits
so you dont have to compile after editing a .sq file
v
Yeah, okay got it. Since I compile via terminal, I just execute the generate task manually 🤷 I'll give the plugin another try
p
The advantage is rather that the code change on the fly and you can interact with it and write other code without building in between
👍 1
2 Views
Open in Slack
PreviousNext
Powered by