Newest at the top
| 2025-02-11 17:58:02 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Ping timeout: 252 seconds) |
| 2025-02-11 17:57:36 +0100 | jespada | (~jespada@2800:a4:2230:3e00:3974:82a3:7f20:1404) jespada |
| 2025-02-11 17:55:54 +0100 | jespada | (~jespada@2800:a4:2211:9c00:4cb1:4c0:c141:d649) (Ping timeout: 265 seconds) |
| 2025-02-11 17:53:41 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-11 17:53:08 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-02-11 17:52:57 +0100 | <kuribas> | regen_schemas.sh or something. |
| 2025-02-11 17:52:56 +0100 | rvalue- | rvalue |
| 2025-02-11 17:52:39 +0100 | <kuribas> | Or if you like, you can put this in a script or a CI/CD pipeline. |
| 2025-02-11 17:49:27 +0100 | <kuribas> | Then pretty print it into some module: https://hackage.haskell.org/package/hasqlator-mysql-0.2.1/docs/Database-MySQL-Hasqlator-Typed-Sche… |
| 2025-02-11 17:49:01 +0100 | <kuribas> | You fetch the table info from the connection: https://hackage.haskell.org/package/hasqlator-mysql-0.2.1/docs/Database-MySQL-Hasqlator-Typed-Sche… |
| 2025-02-11 17:47:01 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-02-11 17:46:40 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 252 seconds) |
| 2025-02-11 17:46:15 +0100 | rvalue- | (~rvalue@user/rvalue) rvalue |
| 2025-02-11 17:45:26 +0100 | prasad | (~Thunderbi@2601:243:c001:3f07::5c) |
| 2025-02-11 17:44:30 +0100 | <kuribas> | kaol: It reads the information schema of the given database. |
| 2025-02-11 17:44:12 +0100 | <kaol> | Schema? As in from pg_dump output or some other representation? |
| 2025-02-11 17:44:08 +0100 | <kuribas> | kaol: this way you don't need access to a DB to compile the code. |
| 2025-02-11 17:43:54 +0100 | <kuribas> | well, export to a haskell value. |
| 2025-02-11 17:43:39 +0100 | <kuribas> | kaol: in my library you export the schema to a haskell type, then feed it to TH to get your types. |
| 2025-02-11 17:43:08 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2025-02-11 17:43:05 +0100 | <kaol> | Feed the schema dump to TH to get types. |
| 2025-02-11 17:43:00 +0100 | <euouae> | kaol: so from your perspective the best benefit is to learn postgresql/sql as best as one can |
| 2025-02-11 17:43:00 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-02-11 17:42:55 +0100 | ft | (~ft@p4fc2a610.dip0.t-ipconnect.de) ft |
| 2025-02-11 17:42:46 +0100 | <kuribas> | kaol: you cannot check against the schema without including it as types... |
| 2025-02-11 17:42:37 +0100 | <kaol> | My dream is something I can just give pg_dump -s and it'd use it for everything. |
| 2025-02-11 17:42:15 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2025-02-11 17:42:03 +0100 | <kaol> | Or duplicate the schema. |
| 2025-02-11 17:42:02 +0100 | <tomsmeding> | (please don't make me run a database to compile your code) |
| 2025-02-11 17:41:40 +0100 | <kaol> | Or type safety. It doesn't even solve the whole problem unless you access the DB schema to check it against it too. |
| 2025-02-11 17:41:26 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-02-11 17:41:24 +0100 | <kuribas> | Yeah, my library is meant for when you want to compose dynamic queries. If you just need a static query, then *-simple is the easiest way. |
| 2025-02-11 17:41:00 +0100 | <kaol> | Composable is kind of no op if you write the query only once. |
| 2025-02-11 17:40:44 +0100 | <kaol> | If I'd have a use case for constructing queries dynamically routinely I might consider some other library. |
| 2025-02-11 17:39:47 +0100 | <kuribas> | opaleye? |
| 2025-02-11 17:39:45 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 248 seconds) |
| 2025-02-11 17:39:32 +0100 | <kaol> | Queries as profunctors is as natural as I've ever seen anything to be. |
| 2025-02-11 17:39:28 +0100 | <kuribas> | my library tries to be as close as possible to SQL, but remaining composable and type safe. |
| 2025-02-11 17:38:51 +0100 | <kaol> | I think much better by writing and thinking in SQL than trying to play ship bottle building game with some other abstraction. |
| 2025-02-11 17:38:34 +0100 | <kuribas> | no PostgreSQL yet though... |
| 2025-02-11 17:38:22 +0100 | <kuribas> | euouae: shameless plug, my sql generator library https://hackage.haskell.org/package/hasqlator-mysql-0.2.1 |
| 2025-02-11 17:37:50 +0100 | <euouae> | I do use PostgreSQL so it's nice that hasql uses it too |
| 2025-02-11 17:36:57 +0100 | <euouae> | kaol: ORM in general or just that aspect? |
| 2025-02-11 17:36:27 +0100 | <kaol> | hasql is my default choice. Anything that tries to model anything by duplicating table definitions in the source is sure to raise my blood pressure. |
| 2025-02-11 17:36:24 +0100 | <euouae> | how about db migrations? by hand? |
| 2025-02-11 17:35:04 +0100 | <EvanR> | keeping it simple |
| 2025-02-11 17:34:56 +0100 | <EvanR> | I've used sqlite-simple and postgres-simple |
| 2025-02-11 17:34:26 +0100 | <euouae> | including their relationships |
| 2025-02-11 17:34:20 +0100 | <euouae> | I was using SQLAlchemy on Python and it works nicely, I was able to declaratively put together all the tables of the schema |
| 2025-02-11 17:34:00 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 276 seconds) |