`--ephemeral` should be the default?

[bergundy]

`--ephemeral` should be the default?

[cretz]

I gather that the majority of users do not want persistence by default.

I actually agree with this. But having data not persisted should still be opted into I think so it's clear to the user.

Regardless, I just don't see why it's so important to change the current default instead of leaving it the way it always has been. Is there something that is causing this issue to be opened? Are there complaints or ergonomics issues for anyone's setup? Or is it just a random idea to change existing default? If the latter, there is no benefit over opting into data loss.

If the default option of using a file is a problem, we can force them to choose, but changing the default to loss of data seems like you're only causing trouble to save a few CLI arg characters. Just type the arg and move on as all others have that need ephemeral.

it's not like people lose their data.

Yes they do. They fire up Temporalite, then restart it, and wonder why their data is gone unlike the last time they used Temporalite where data survived over restart. Sure it's not production data loss or something, this isn't even a production server, but the cost of changing the default is still higher than the cost of leaving it.

[bergundy]

it's not like people lose their data.

What I meant by this is that if they already had a DB, they upgrade and ephemeral is the default, the data in their DB is preserved.

I have no strong opinion, feel free to close this issue, I brought it up as a suggestion.
I don't think there's that much value in a "yolo" or "start-ephemeral" command, it doesn't save much. Having the explicit params at least informs the user what's going to happen (creating a default namespace and opting into ephemeral mode).

[jlegrone]

if they already had a DB, they upgrade and ephemeral is the default, the data in their DB is preserved.

I think the concern is not so much about losing the old data, but that you could conceivably upgrade and then not notice that new workflow executions are not being persisted until the next restart.

I'll go ahead and close this for now, but definitely happy to entertain new subcommands in the future if we think they bring significant value.

[cretz]

I think it's reasonable to have a default of file persistence. Even if it wasn't reasonable, it's the current expectation by the many users of this binary, no need to change it now. What's the harm of providing the single CLI arg? Especially compared to harm of incompatibly changing everyone's default to stop persisting to disk.

I don't share this preference personally even though I always use Temporalite ephemerally in my use cases.

[bergundy]

Based on 0 data, I gather that the majority of users do not want persistence by default.

Reasons that could back my theory:

• temporalite is often used in CI where ephemeral is a better default
• defaulting to persisting in a non-user supplied location could lead to surprises when restarting and finding workflows being scheduled and test workflow IDs being taken
• current issue with missing permissions to write to the default location (reported by some Windows users) would be entirely avoided
• easier to upgrade versions that require schema changes

As far as breaking compat, the implication isn't too bad, it's not like people lose their data.

[jlegrone]

I gather that the majority of users do not want persistence by default.

I actually agree with this. But having data not persisted should still be opted into I think so it's clear to the user.

I also agree that the majority are probably using the ephemeral mode. But I also think it's important that any non-durable usage is self-documenting. This is why there is no short form of the --ephemeral flag and no environment variable to set it by default (which I'm just now realizing we should add a code comment about).

Although it's not currently recommended, my vision is for Temporalite to be stable enough for small-scale production usage in addition to CI and local dev. I don't think we should ship defaults that cause users to second-guess whether their configuration could become unsuitable for production at any time.

[jlegrone]

That said we could always add a new subcommand for convenience (temporalite yolo??) which is like start but defaults to ephemeral, creates a default namespace for you, and is explicitly for these throwaway use cases.

[cretz]

temporalite start-ephemeral I think would be a great compromise here. Granted you've really only saved a space, a dash, and maybe a namespace name, heh.