Logs: freenode/#haskell
| 2021-04-06 10:21:24 | <Maxdamantus> | tdammers: I feel like even in game programming, that model ("entity" something something) seems mostly useful if you're intending to share the state incrementally across a network at some point. |
| 2021-04-06 10:21:59 | <Maxdamantus> | So it still doesn't seem inherently better as an in-memory model. |
| 2021-04-06 10:22:09 | <kuribas> | haskellstudent: that will not always work |
| 2021-04-06 10:22:15 | × | royal_screwup211 quits (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed) |
| 2021-04-06 10:22:15 | × | royal_screwup21 quits (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed) |
| 2021-04-06 10:22:27 | <tdammers> | Maxdamantus: the main reason this is done is performance, and specifically, cache performance. The idea is that you lay out your data structures such that for the most performance critical operations, the data you need is laid out linearly in memory, so you can zoom over it with the minimum amount of cache misses |
| 2021-04-06 10:22:35 | → | royal_screwup21 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) |
| 2021-04-06 10:22:46 | × | rdivyanshu quits (uid322626@gateway/web/irccloud.com/x-zbthekzvhrqpupmy) (Quit: Connection closed for inactivity) |
| 2021-04-06 10:23:00 | <haskellstudent> | kuribas: can you give an example where it would not work? |
| 2021-04-06 10:23:53 | <tdammers> | the alternative, the classic object graph, is really really bad for cache performance: when traversing a list of objects, you're walking a list of pointers to arbitrary heap locations, and each of those pointers is relatively likely to cause a cache miss. And if those objects then contain pointers to other objects, it gets worse. |
| 2021-04-06 10:24:00 | <kuribas> | haskellstudent: if the type changes in incompatible ways |
| 2021-04-06 10:24:52 | <haskellstudent> | kuribas: of course if i removed a field from the json event for example the older services could no longer read it, but they can "ignore" it (logging a parsing error) while they are still running until all old versions of the service are upgraded |
| 2021-04-06 10:24:59 | × | pavonia quits (~user@unaffiliated/siracusa) (Quit: Bye!) |
| 2021-04-06 10:25:03 | <tdammers> | the schema migration problem exists regardless of sql or not-sql |
| 2021-04-06 10:25:08 | × | Guest66883 quits (~textual@2603-7000-3040-0000-e045-d645-2e21-7cec.res6.spectrum.com) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-04-06 10:25:11 | <kuribas> | this |
| 2021-04-06 10:25:15 | → | tomboy64 joins (~tomboy64@unaffiliated/tomboy64) |
| 2021-04-06 10:25:16 | <tdammers> | and the mitigation strategies are largely the same too |
| 2021-04-06 10:25:28 | <tdammers> | the disadvantage of a "schema-less |
| 2021-04-06 10:25:33 | <tdammers> | " store is that the schema is implicit |
| 2021-04-06 10:25:45 | → | Alleria_ joins (~AllahuAkb@2603-7000-3040-0000-51cb-91e5-ecfa-0406.res6.spectrum.com) |
| 2021-04-06 10:25:57 | → | zebrag joins (~inkbottle@aaubervilliers-651-1-244-162.w83-200.abo.wanadoo.fr) |
| 2021-04-06 10:26:20 | <kuribas> | tdammers: yeah, it's the same problem with clojure. The idea is that you don't need schemas and static structure, but you still end up with it, just in an implicit and ad-hoc way. |
| 2021-04-06 10:26:22 | <haskellstudent> | tdammers: not necessarily. its can be very explicit, its just defined e.g. in haskell rather than both in the db and in haskell |
| 2021-04-06 10:26:57 | <tdammers> | if you define the schema, then it's no longer schema-less, is it |
| 2021-04-06 10:27:27 | × | royal_screwup21 quits (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Ping timeout: 260 seconds) |
| 2021-04-06 10:27:28 | × | lawt quits (~lawt@c-73-151-3-92.hsd1.ca.comcast.net) (Ping timeout: 268 seconds) |
| 2021-04-06 10:27:30 | <haskellstudent> | correct, i never said it would be. there is no such thing. but i dont need to pause the db to do a migration, that was the only point. |
| 2021-04-06 10:28:09 | <tdammers> | a decent rdbms can do schema modifications without downtime too |
| 2021-04-06 10:28:27 | <tdammers> | you just can't have inconsistent data at any point |
| 2021-04-06 10:28:36 | <tdammers> | like, half of the records in the old schema and the other half in the new |
| 2021-04-06 10:28:42 | <tdammers> | but that's a design feature, really |
| 2021-04-06 10:29:31 | <kuribas> | tdammers: doing a huge transaction to migrate may slow the DB down though... |
| 2021-04-06 10:30:09 | <tdammers> | sure. but so can a huge sweep over a "schema-less" database that changes all the records (documents, whatever) to match the new structure |
| 2021-04-06 10:30:37 | → | royal_screwup21 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) |
| 2021-04-06 10:32:01 | × | Alleria_ quits (~AllahuAkb@2603-7000-3040-0000-51cb-91e5-ecfa-0406.res6.spectrum.com) (Ping timeout: 245 seconds) |
| 2021-04-06 10:32:50 | <haskellstudent> | tdammers: but in the case of e.g. an immutable event history that is what i might want. in an sql db i would probably have to create have to create a new table then with the new "incompatible" version. but then i would end up with another table for each such schema change that i ever made. |
| 2021-04-06 10:33:09 | <kuribas> | and then, how do you synchonize the changes in the DB with the service version? |
| 2021-04-06 10:34:18 | <kuribas> | or do let the service detect the previous database version, and handle it gracefully? |
| 2021-04-06 10:35:10 | <olligobber> | No instance for (Language.Haskell.TH.Syntax.Lift TH.Type) |
| 2021-04-06 10:35:12 | <olligobber> | >:( |
| 2021-04-06 10:35:21 | <haskellstudent> | kuribas: service v1 keeps reading v1 events as usual, service v2 still knows how to read the v1 events but also v2 |
| 2021-04-06 10:35:27 | <tdammers> | note that it is perfectly possible to implement many changes to an SQL schema in a backwards-compatible way |
| 2021-04-06 10:36:00 | <tdammers> | so what exactly is the difference between v1 and v2? typically, such a change will be "widening" rather than completely changing the schema |
| 2021-04-06 10:36:13 | <kuribas> | tdammers: I suppose you keep your schemas backward compatible unless it because too messy, then run a breaking migration? |
| 2021-04-06 10:36:15 | <tdammers> | add a field, extend a field type to support more values, etc. |
| 2021-04-06 10:36:28 | <haskellstudent> | typically, yes. but we were talking about incompatible chanegs |
| 2021-04-06 10:36:37 | <haskellstudent> | (deleting or renaming a field) |
| 2021-04-06 10:36:56 | → | geowiesnot joins (~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) |
| 2021-04-06 10:36:57 | <tdammers> | and even when you make "breaking" changes, you can often *still* uphold backwards compatibility, e.g., by providing views that have the same structure and name as the old table |
| 2021-04-06 10:37:30 | <tdammers> | deleting fields: don't delete, make optional. |
| 2021-04-06 10:37:38 | <tdammers> | renaming is just delete + add |
| 2021-04-06 10:37:42 | <tdammers> | so just do that |
| 2021-04-06 10:37:58 | <tdammers> | add a column, make the old one optional, and maybe add a constraint saying you can only have one or the other, but not both |
| 2021-04-06 10:38:05 | <tdammers> | or do the "compatibility view" trick |
| 2021-04-06 10:38:39 | <kuribas> | tdammers: so you use a stored procedure to implement the old table "view"? |
| 2021-04-06 10:40:05 | <tdammers> | no, just a plain view will usually work |
| 2021-04-06 10:40:09 | <tdammers> | except for inserts ofc |
| 2021-04-06 10:40:34 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 260 seconds) |
| 2021-04-06 10:40:41 | <kuribas> | how does that work for JSON? |
| 2021-04-06 10:41:02 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-04-06 10:41:16 | <tdammers> | JSON? I'm talking about relational schemas. JSON you put in there is pretty much opaque. |
| 2021-04-06 10:42:11 | × | frozenErebus quits (~frozenEre@37.231.244.249) (Ping timeout: 240 seconds) |
| 2021-04-06 10:43:48 | → | olligobber1 joins (olligobber@gateway/vpn/privateinternetaccess/olligobber) |
| 2021-04-06 10:44:26 | × | olligobber quits (olligobber@gateway/vpn/privateinternetaccess/olligobber) (Ping timeout: 265 seconds) |
| 2021-04-06 10:46:08 | <olligobber1> | merijn, hey, why can't I lift a type? |
| 2021-04-06 10:46:21 | <olligobber1> | `No instance for (Language.Haskell.TH.Syntax.Lift TH.Type)' |
| 2021-04-06 10:46:35 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 260 seconds) |
| 2021-04-06 10:46:58 | <olligobber1> | lol |
| 2021-04-06 10:46:59 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-04-06 10:47:03 | <olligobber1> | merijn, wb |
| 2021-04-06 10:47:18 | olligobber1 | is now known as olligobber |
| 2021-04-06 10:48:20 | <haskellstudent> | tdammers: ok so zero downtime migrations might be possible, but it seems like there are still traps and while they could be avoided it seems more complicated than just having a kv store/table for my events so i know exactly how the system will behave. example: https://gocardless.com/blog/zero-downtime-postgres-migrations-the-hard-parts/ |
| 2021-04-06 10:50:16 | × | MindlessDrone quits (~MindlessD@unaffiliated/mindlessdrone) (Ping timeout: 268 seconds) |
| 2021-04-06 10:51:35 | → | royal_screwup211 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) |
| 2021-04-06 10:51:55 | → | MindlessDrone joins (~MindlessD@unaffiliated/mindlessdrone) |
| 2021-04-06 10:51:57 | × | jpds quits (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 240 seconds) |
| 2021-04-06 10:53:06 | → | heatsink joins (~heatsink@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-04-06 10:54:06 | → | rdivyanshu joins (uid322626@gateway/web/irccloud.com/x-frmbfjisqfxmhgqn) |
| 2021-04-06 10:55:38 | → | jpds joins (~jpds@gateway/tor-sasl/jpds) |
| 2021-04-06 10:56:24 | × | ukari quits (~ukari@unaffiliated/ukari) (Remote host closed the connection) |
| 2021-04-06 10:57:04 | <olligobber> | merijn, can I have template haskell help pls? |
| 2021-04-06 10:57:21 | → | ukari joins (~ukari@unaffiliated/ukari) |
| 2021-04-06 10:58:06 | × | gnumonic quits (~gnumonic@c-73-170-91-210.hsd1.ca.comcast.net) (Ping timeout: 240 seconds) |
| 2021-04-06 10:58:25 | <merijn> | olligobber: Eh, maybe? I'm not really a TH expert :p |
| 2021-04-06 10:58:43 | × | heatsink quits (~heatsink@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 260 seconds) |
| 2021-04-06 10:58:45 | × | NinjaTrappeur quits (~ninja@unaffiliated/ninjatrappeur) (Quit: WeeChat 3.1) |
| 2021-04-06 10:58:48 | <olligobber> | merijn, I'm getting No instance for (Lift Type) |
| 2021-04-06 10:58:54 | <olligobber> | `No instance for (Language.Haskell.TH.Syntax.Lift TH.Type)' |
| 2021-04-06 10:59:04 | <merijn> | Oof...cursed error |
| 2021-04-06 10:59:26 | → | NinjaTrappeur joins (~ninja@unaffiliated/ninjatrappeur) |
| 2021-04-06 10:59:34 | <olligobber> | mmhmm |
| 2021-04-06 10:59:40 | <merijn> | I mean, seems perfectly normal there is no Lift instance for Type, but I dread the code that requires that :p |
| 2021-04-06 11:00:00 | → | Alleria joins (~textual@2603-7000-3040-0000-e045-d645-2e21-7cec.res6.spectrum.com) |
| 2021-04-06 11:00:08 | <olligobber> | I'm just trying to take in a function's name and get its type in an Exp |
| 2021-04-06 11:00:23 | Alleria | is now known as Guest63000 |
| 2021-04-06 11:00:25 | <olligobber> | so I guess I want to lift the string instead of the type? |
| 2021-04-06 11:01:07 | <olligobber> | also, why wouldn't there be a lift instance for type? |
| 2021-04-06 11:01:11 | × | jonathanx quits (~jonathan@h-176-109.A357.priv.bahnhof.se) (Remote host closed the connection) |
| 2021-04-06 11:01:34 | <olligobber> | lol can I just add deriveLift $ mkName "Type" to my source? |
All times are in UTC.