trek

• I need to pass the input groups created_at in.
• Some thoughts on the created_at being client side. I get that it makes testing easier but it breaks the value of having a created_at column, record the order of the migrations were applied.
• I wonder if it faster to use the transaction id then timestampz.
• Either way I want to get rid of that restriction
• So this changes the tests. Instead of providing a way to make them equal, I’ll provide my own equivalence function to compare them.
• Or I have to use libfaketime.
• Hmm … on further thought I do like the client side created_at but I think there should also be an auto incremented sequence to order the migrations. The created_at is not to make an order but to give a rough sense of when it was created.
• I would like to rewrite this entirely in sql
• This becomes easier to test if the migrator is single threaded. Which it is at first but I am not sure if I should rely on it.
• No I don’t think I should because that would make adding multithreaded behavior harder. Yes I should pass in a equivalence function. I can test that order is preserved on sequencial calls but not their exact numbers. So the order of the migrations hashes going in order of the hashes going out.
• So the order field doesn’t show up.
• then I can use equals
• I’m debatting writing the insert as a single statement.
• It just makes a query that needs a lot of inputs. It increases the chance for a row tranposition error.
• Starting to wonder if I should use something other than postgresql simple. I’ll stick with it for now.
• So should I make the big query? Yeah.
• It will probably let me remove some code.
• I’m starting to feel like I should just make the postgresql function interface first.
• I’ll just write the tests with Haskell.
• This will also change the interface to take a String instead of a DB ()
• Which makes more sense and is simpler then adding a fromString :: String -> DB ()