I think you’re probably right in the general case, but I think in OP’s case - a card game with likely single to double digit users and low data volume - this is unlikely to be an issue and certainly I wouldn’t say “there is no way” to do this. There are just some risks and if folks understand those risks, then they can find ways to work around them in the interim until they feel like moving to an approach that more closely resembles what you’re describing.
seeplusplus
D4no0
Maybe, but at the same time I think that using ecto migrations for data migrations is wrong usually. This is especially true in cases where you want to do these kind of migrations in multiple steps to avoid any potential downtime.
0
dimitarvp
They should be Ecto migrations so Ecto itself can keep track of what’s been migrated and what not but they can otherwise be pure SQL statements inside, and I prefer that as well; using Ecto constructs inside data migrations is extremely brittle and it absolutely is not future-proof.
0
larshei
Nice, I enjoyed reading all the anwers.
The first goal was to get to a working app as fast as possible.
Now the basic gameplay and the required stuff “around” it is in place - I even added a very simple/dumb bot, so it is possible to play with less than 4 players. Time to clean up.
All criticism about storing and just loading the terms is totally valid - storing anything binary almost always turns out to be a horrible idea once a schema changes 
For sure, but if I have to do the conversions from maps, then I dont really need to store it as binary anymore I think - instead I can store json/bson in the database and convert it to my structs on reading it back → Should be identical on the app side, but is then queryable on the database level as well.
Converting the nested data structures was not on my wanted list, buuuuut …
… Would it be a good option to just use embedded ecto schemas instead of plain strucs everywhere? IIRC, casting to a schema containing nested schemas will convert the nested maps to structs as well - Will give that a try!
Neat, I’ll keep that option in mind.
0
cevado
My suggestions were with the spirit of “the least amount of work that is the most future proof as possible”. I try to approach stuff this way so it’s simple to change directions in the future.
yep… that was one of my suggestions in the first reply 
but i’d use it only if you’re already using structs, if it’s just maps i’d keep it that way with jsonb and only add the embedded schema when stuff starts getting messy.
0
cevado
it’s off-topic but I see migrations as db “book keeper”, any relevant change or important operation I like to keep it as migration for historical purposes. in case is something to be executed manually, i’d just add the timestamp of the migration to the schema_migrations table and that’s it. but i don’t think this applies here
3
larshei
Ah, here, somehow I missed that 
Probably the best solution!
All my data is stored in structs already 
0
sleipnir
Hi there! Your project sounds like a lot of fun and a great use of Elixir/LiveView! 
If you’re open to exploring alternative approaches, you might want to check out the Spawn Actor Framework. It’s designed for managing distributed state with actors, offering built-in state persistence and recovery mechanisms. It could simplify handling game states, even across app restarts or deployments.
Let me know if you’d like more details—happy to share! 
1