This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-06-08
Channels
- # asami (15)
- # babashka (123)
- # beginners (174)
- # calva (4)
- # cider (6)
- # cljdoc (4)
- # cljs-dev (4)
- # cljsrn (18)
- # clojure (268)
- # clojure-australia (1)
- # clojure-europe (107)
- # clojure-ireland (5)
- # clojure-nl (2)
- # clojure-uk (18)
- # clojured (1)
- # clojurescript (21)
- # conjure (4)
- # cursive (38)
- # data-science (1)
- # datahike (6)
- # datomic (4)
- # events (1)
- # fulcro (9)
- # graalvm (16)
- # helix (6)
- # honeysql (4)
- # instaparse (3)
- # jobs (1)
- # observability (15)
- # pathom (7)
- # pedestal (15)
- # polylith (9)
- # practicalli (1)
- # re-frame (6)
- # remote-jobs (2)
- # specter (7)
- # sql (16)
- # tools-deps (1)
- # vim (5)
- # xtdb (1)
are there any fixture/test data generation libraries like factory_bot (https://github.com/thoughtbot/factory_bot/)? (maybe I should ask this in #testing, but the main domain would be interaction with sql)
@UEENNMX0T I'm curious what you ended up using for this sorta thing. Did you find something you like?
I did not. #lambdaisland released https://github.com/lambdaisland/facai since then which looks cool but I’ve not had a changes use it yet
That looks pretty good. I'll give it a spin. I do wonder why the topic of factories isn't discussed here so often.
As I see it, plain maps are much easier to build and combine in a test function than an ORM-built object, especially when there are no methods or state to handle. Factory bot is needed because rails models are massive and complex.
since you're not dealing with an ORM, factory bot approach is an overkill - you can use something like faker: https://github.com/paraseba/faker and generate data sets for inserting via jdbc
We often write Specs for our tables and use those to generate random, conforming data for tests.
The nice thing about that approach is that the Specs serve double-duty: you can use them to validate data before inserting into the DB and you can also use them to drive generative testing, either through generative data production or directly to test exercise code that operates on what could come out of the database.
well, the benefit of factory_bot isn’t so much that it interfaces with the ORM (tho that’s helpful), but that you can define the structure of the data and generate “random” versions while also over-riding specific values. i am particularly fond of the “trait” system that lets you bundle a set of values to a name, so for instance, if an admin user needs to have their “role” set to “admin” and they need to be added to the “admin” table, in the :admin
trait you can do that and then just call fb.create(:user, :admin)
and it’ll set the role and insert into the admin table
Spec and faker work when you only want to get a random conforming object, but it gets harder/more annoying when you want to construct more elaborate set-up data.
one method would be to write a wrapper function that does that kind of conversion/set up for you, but at that point you’re re-implementing the factory_bot-style logic without the reusability of a factory_bot-style library
SQL migrations script question for postgresql
I'm writing an SQL migration script to update the names of 10 different people in a table. I know the unique id's of each person and their new name.
Is there a better approach than just using a migration script with 10 separate update statements ?
The project uses ragtime for the subscriptions and .up.sql
scripts in resources/migrations.
The project doesn't merit anything fancy as it will be replace at some point.
update table t
set name = old.name
from (select id, name from (values (1, 'new-name-1'), (2, 'new-name-2')) as old(id, name)) old
where old.id = t.id;
a CTE combining id, old name and new name, then update set new name where id = id and name = old_name
Sounds intriguing, I'll take a look. Thanks