How do you guys do feature switches over changes t...

# squarelibraries

[ursus]

How do you guys do feature switches over changes that require sqldelight migrations? Can I have a conditional .sqm somehow?

[Neil Miller]

Conditional schema migrations don't exists. You could use code migrations: https://sqldelight.github.io/sqldelight/latest/jvm_sqlite/migrations/#code-migrations

[Neil Miller]

but I wouldn't recommend any schema changes via that route as it will break things

[ursus]

so how do you manage, if a feature A is behind a feature flag, and needs to be able to be turned off

[Neil Miller]

Schema changes to support the feature are always present, we turn it on or off at higher levels in the app.

[ursus]

okay but that assumes additive changes, which yea isnt a problem

but what about non compatible changes, like changing what FK points to and stuff like that?

(assume you dont need to preserve data and you'd just want to drop the current table Foo and recreate it (with FK pointing to different table)

[Neil Miller]

I'd need more context. Are these compile time flags? Where is this running? etc

[ursus]

ideally remote, so feature can be turned off if misbehaving

so runtime

[ursus]

i currently dont support this due to the migrations -- im just ideating

[Neil Miller]

Yeah, that's something that's very much outside what SQLDelight is designed to deal with

[ursus]

well, compile time flag would be a start; since I feel i cannot do even that now

yet every big app uses feature flags, so..can they simply not be able to do nonadditive sqlite migrations?

[Neil Miller]

Can't speak to anyone else, but we never do that, the database is the same regardless of feature flags

[Neil Miller]

If you can afford to blow it away, defining multiple database schemas might work, but it sounds like a pain

[ursus]

well, I dont really see a way, other than having Foo and Foo2 at the same time

[Neil Miller]

That is the other option

[ursus]

but yes if that acts as a FK somewhere then.. you need to replicate the whole hierarchy ugh

[ursus]

well my case currently is...

lets say its like slack; each message belongs to a conversation, and conversation belong to user

and a new feature comes along that allows multuple workspaces

so conversation now belongs to workspace, and workspace belongs to user

so a table was inserted between User and Conversation (table workspace userId references user.id, table conversation workspaceId references workspace.id)
how would you manage this?
youre saying to merge this change, let the migration play, but now..you need to insert a conversation differently, otherwise it blows up on FK integrity

[ursus]

okay so I guess the only way is to treat both branches of feature switch as if the migration happened, which granted is true

-- oh well

so the sum of the story is you cannot feature switch over migrations it seems and both branches of execution need to take that into account

[Neil Miller]

We'd probably have a dummy workspace defined, and use that to link users and conversations in the feature off configuration.

[Neil Miller]

Or maybe there's a clear primary

[ursus]

yea..if I give up undoing the migration then options open up; I was just hoping to not touch the FF off branch

[ursus]

thank you!

[Neil Miller]

no problem

[ursus]

btw do you have opinion on when to apply feature switches? immediately at sync time vs caching them and applying on next app start

[Neil Miller]

I think we have a mix of the two, definitely some that are immediate

[ursus]

okay so it should be optional for a feature to pick