Its not unusual, but neither you nor I know what the topic starter intentions are. It might be that they don’t know about application env, or they are just following a bad practice. Or it might be that they have a completely valid use-case, though not exactly like the one you described (cause no server-side program wants to keep in memory all settings of all users)
Asd
lcabrini
Good point, I should have made that clear. It would mostly be things like the business contact details (address, phone number, etc) that would show up on invoices, receipts and the like. They could change, but probably not frequently, although I did have a client who had to move 4 times within Accra in a single year).
Since Internet connectivity can be a challenge in some areas and I’d prefer not to have to sit in a bus for 12 hours just to go to Tamale and change somebody’s configuration file, I think storing the settings in a way that the client can update themselves is not a bad idea. Power outages do happen and so persisting the settings is also required.
This is not a massive application with thousands of users, so caching the settings table would not really be needed. However, don’t fault me for being curious about how it would typically be achieved in Elixir/Phoenix. I do like the idea of memory caching the settings table if it makes sense and doesn’t lead to any other possible problem.
0
lcabrini
I do understand environment variables. I don’t mind that solution, but how do I persist changes to the environment? Because it’s a long distance from here to northern Ghana and I really wouldn’t want to travel all the way every time they’ve had lights off. It could end up with me doing nothing but sitting on a bus.
The big benefit for me with the database is that I can have changes backed up with everything else. I have cron jobs (or timers, or whatever that systemd replacement is called) to back up the database regularly. I really want to limit the amount of things to be backed up. That being said, if environment variables is the way to go, so be it.
0
lcabrini
Asd
It sounds like user session state and I personally do this with Nebulex. Even if you don’t plan to have a lot of users, its very nice to have a memory limit on this kind of data, so I’d use caching instead of unlimited ets table. Just set up the Nebulex with multilevel cache adapter like local cache level on top of db cache level.
Nebulex will solve a lot of scaling problems you may encounter in the future
- Memory limits. You will have a safe code once the amount of users explodes
- Distributed cache. If you will have more than 1 instance of the app using the same database, you will need to sync the cache changes (when write happens). With Nebulex you could just swap the local cache to replicated one
- Atomicity. You can have transactions to change the multiple settings at once on all levels (even in distributed model). For example, user may change address and postal code and they want this change to be atomic
0
lcabrini
Perfect. It is user session state, with the following bonus features.
- a change to the “settings” part of the session acquires a mutex/lock
- the changes are persisted somewhere (database or some other place)
- the “settings” part of the session is reloaded from storage
- the lock is released
That is more or less how my Go implementation worked and it did what it needed to do. Multiple “go routines” (think threads) could access the struct (which was what I used for settings). The write method acquired the lock and updated the settings table before releasing the lock. This did what it needed to do for me. It never gave me any problems. I’m curious as to how that best translates into Elixir. It seems GenServer is what I’m looking for?
0
lcabrini
lcabrini
derek-zhou
Then they are application data, not configurations. I’d suggest to keep them in Postgres and skip the caching layer. Any caching layer is a data consistency risk; and it appears that you do not need to access those information so frequently that it will materially hurt performance.
3
garrison
Agreed, and if you’re not already using Postgres I would say just go with SQLite and Litestream for backups. I doubt an ETS table would even be noticeably faster than SQLite for something like this, and SQLite works with Ecto out of the box.
1