#elixir-lang - 06 July 2019
« Back 1 day Forward 1 day »
[04:50:44] cmk_zzz: I need help with Phoenix form. I have a row of checkboxes in a table. Each represent an id. On submit I want to get a list of checked ids, [1,2,3,4]. But I can't figure out how to do this. Any ideas?
[08:12:08] serafeim: is there a difference between 1. `with z <- 3, y <- z, do: z+y`, 2. `with z <- 3, y = z, do: z+y` and 3. `with z = 3, y = z, do: z+y` ? the result i get is the same in all cases (6).
[08:12:52] serafeim: i'd like to understand what's the difference when i use `=` instead of `<-` with `with`. if there's a difference :)
[08:13:05] mdbm: I want to make a quiz, so visitors are presented questions they must answer. I have to remember somehow which questions have already been answered, in order to avoid asking them the same answer multiple times. If I do server-side rendering, where do I store the list of already answered questions for each visitor(session) ? Where do I store this "session data"? I'm very confused guys plz help:'(
[08:14:14] serafeim: dysfun: so using `<-` it will return the non-matched value. while using `=` it will raise the not match exception ?
[08:14:24] mdbm: serafeim, so I use the database as a temporary session cache? they must not create accounts, so the database is sued as a store for temporary session data, that's okay to do?
[08:15:37] serafeim: mdbm: the problem with the default elixir session storage is that there's a limit to how much data you can save there
[08:16:15] mdbm: serafeim, but, what about processes/OTP GenServers/and so on? They can be used as session data cache for each visitor?
[08:17:37] serafeim: dysfun: phoenix decided to use the plug default for session storage. couldn't it decide to use something completely difference? after all you as a developer talk to the framework
[08:18:28] mdbm: dysfun, how does the plug session storage work? I.e. where does it really store session data?
[08:19:41] mdbm: then the storage is pretty limited as serafeim mentioned. i.e. for my quiz idea, I need to store all questions answered, but what if there are really many questions and the ID's are long UUID
[08:20:38] mdbm: so what about a GenServer process? Is it another viable alternative to the database?
[08:20:41] serafeim: mdbm: but you could use the ETS storage: https://phoenixframework.org/blog/sessions (although its not recommended)
[08:22:10] mdbm: dysfun, but what about server process? sorry to insist, but I thought that was a way to use Erlang/OTP's power. And if I udnerstood, it's state in server's memory that is actually scalable horizontally
[08:23:17] serafeim: for the session, you'll get a cookie like this `SFMyNTY.g3QAAAAGbQAAAAtfY3NyZl90b2tlbm0AAAAYakFJV1V4a0ZjWmFMVmMxSlhwMFN3cEdQbQAAAAxhdXRob3JpdHlfaWRkAANuaWxtAAAADmF1dGhvcml0eV9uYW1lbQAAAAEgbQAAAAtwZXJtaXNzaW9uc2wAAAABbQAAAAlzdXBlcnVzZXJqbQAAAAd1c2VyX2lkYQFtAAAACHVzZXJuYW1lbQAAAARyb290.1jyWUwbKspIiNY1GJ5E4UMOWIA4BWTxIKkYz8wTXDbA`. if you take the part between the dots and base64 decode it you'll see your
[08:23:28] dysfun: memory is for what you are working on now. you're not working on it between requests
[08:24:26] mdbm: dysfun, I can use the memory for session data, if I maintain a key in a structure in memory to identify the session data for each visitor
[08:24:55] dysfun: but all you're doing is managing a cache, and cache management is one of the hard problems of computer science
[08:25:42] mdbm: dysfun, and if I sue a database for this, it's a cache as well. is data in a database easier to handle/manage than data in a server process?
[08:28:05] mdbm: dysfun, there ahve been quiz applications before we talked about stateful frontend applications. How do these applications remember which questions users have answered in a session
[08:28:19] serafeim: when the user firsts visit the page start a session, give it an id and save it to the database. then you can keep everything to your db.
[08:30:43] mdbm: serafeim, if you suggest me to store this session data in a database, then I gotta know why this is preferred to session data in memory handled by a server process, it's more efficient to read memory from a process than query a db
[08:31:37] serafeim: mdbm: the database is a trusted and more controlled solution. it is well tested and you know its working.
[08:32:26] serafeim: of course if you want to experiment then do the server process. or do whatever else you like. but for a prod app i'd trust the tried solutions
[08:34:36] serafeim: all i'm saying is to use the easiest solution each time. don't bother with things that you probably won't need
[08:34:56] mdbm: dysfun, yeah I should go old school or SPA, you're absolutely right. But can you share your opinion on why it's hard otherwise (i.e. what make the other solutions talked about hard: maintain/manage session data stored in db or in memory handled by a process). It's very interesting
[08:36:21] mdbm: serafeim, yes that's his solution, I completely forgot we did this way before SPA's
[08:36:51] dysfun: well with SPAs you don't have this problem, you can just shove it in localStorage
[08:36:58] serafeim: dysfun: well i find this more difficult to implement than saving things in the database and running a proc that would delete old data
[08:37:29] mdbm: dysfun, sessionStorage*, actually, not even in a html5 storage mechanism, if I use React, I can just keep in state
[08:39:10] mdbm: it's not difficult, but not very clean? usually you end up with some custom unmaintainable sh*t cobbled together the more your state gets complex
[08:40:36] mdbm: dysfun, exactly, that's why he suggested the DB to persist data across user requests
[08:42:25] serafeim: well the database can also be used for transient data i don't think theres a law forbidding that
[08:42:34] mdbm: dysfun, you could go for old school session data (session files server side as we seen in traditional php applications), but it's not scalable accross mulitple servers. storing in db gives you more flexibility in that sense
[09:23:46] mdbm: serafeim, was reading more about the session plug here: https://phoenixframework.org/blog/sessions
[09:23:48] mdbm: they do not explicitly mention that the actual session data resides IN the cookie, seems to me important information even if it might be obvious for some
[09:25:20] mdbm: serafeim, then I'm also surprised that Phoenix doesn't come with a session storage mechanism (like storing session data in files as php/apache does). Or are these system really considered as obsolete?:-/
[09:26:18] mdbm: dysfun, you know any reason why we do not have a session server-side storage mechanism in Phoenix?
[09:36:10] mdbm: dysfun, and using live view doesn't bring a solution for storing state I guess, I only heard about it
[09:37:41] serafeim: mdbm: i agree that this should be mentioned there. i've stumbled upon it (trying to save too many data to the session) to actually leanr about it :)
[09:38:51] serafeim: mdbm: it has ETS storage through. and you can probably implement a custom database (or redis or whatever) backed one
[09:39:14] mdbm: serafeim, you said earlier ets storage is not recommended, and now it's used for live view?
[09:40:10] mdbm: dysfun, so it brings a complete session management system with it? in this process? garbage collected and all?
[09:41:37] mdbm: yeah I was asking if it includes one, I know its purpose is to have dynamic pages without refresh, like a spa
[09:45:14] mdbm: and that it works through web sockets I guess, but I can't really picture how web sockets/channels brings an alternative to the state storing
[13:36:00] serafeim: for anybody interested this got some trend in HN: https://news.ycombinator.com/item?id=20357055
[19:12:19] ankhers: I asked the other day but I think I missed someones response. Is there a suggested way to add timestamps to a table after the initial migration in ecto?
[19:25:56] ankhers: OvermindDL1: The problem is there are already fields in there and it violates the not null contraint.