Weekly Recap #2

[kaspth]

Here's the second weekly recap!

In last weeks recap, I shared where we were at in code and it looked like this:

# test_helper.rb
Oaken::Data.load_from "test/seeds"

# test/seeds/users.rb
User = Struct.new(:name, keyword_init: true)
memory.register :users, User # Uses the Oaken::Stored::Memory provider.

users.update :kasper, name: "Kasper"

# test/seeds/comments.rb
Comment = Struct.new(:name, keyword_init: true)
records.register :comments, Comment # Uses the Oaken::Stored::ActiveRecord provider.

# NOTE: this comments sample is mainly to demo `records` using a different provider.

But now we've got this:

# test_helper.rb
Oaken::Data.records.preregister ActiveRecord::Base.connection.tables.grep_v(/ar_/)
Oaken::Data.load_from "test/seeds"

# test/seeds.rb
accounts.with name: -> { id.to_s.humanize }
accounts.update :business, name: "Big Business Co." # We're overriding the `name` default here, but the default eases `accounts.update` calls in the tests.

# We're automatically deriving the `name` based off of `:kasper.to_s.capitalize`, and setting the `accounts` `has_many` `:through` which will create a `Membership` class under the hood.
users.with name: -> { id.to_s.capitalize }, accounts: [accounts.business]
users.update :kasper
users.update :coworker

Which I think is a really nice improvement! It also ends up satisfying the Up Next part from last week's recap. It also feels good that the code itself is still just 115 lines.

PRs

• @alexandreruban set us up with a section to add your names in Add initial sponsors names to README.md #10, and @larkro did so in docs: add name to list of sponsors #15. If you want your name in the README too, please follow what docs: add name to list of sponsors #15 did and send your PR!
• In Derive key from type when registering a provider #11 by @alexandreruban, our API changed from register :users, User to register User where we'll automatically tableize the class name.

---

Here's the stuff I worked on:

• I followed up on Derive key from type when registering a provider #11 in Replace Active Support with barebones inflections #12 to remove the Active Support dependency.
• Encourage combining certain fixtures into one file #13 where we started removing the 1-1 model per Fixture file mapping and became more like seeds. So now we've got test/seeds.rb.
• Add Active Record based setup. #14 we hooked up Active Record and closed out Add ActiveRecord as a dependency #5
• Add Inflector setup #16 also a follow up to Derive key from type when registering a provider #11 to extract out our internal inflection work and follow Zeitwerk's inflector extension pattern.
• Preregister refactor #17 when I set up Active Record in Add Active Record based setup. #14 I added a preregister method that'll take ActiveRecord::Base.connection.tables and automatically register each of those. This refactors this a bit. Note: this may also go away soon, since I'm wondering if we should do this work lazily — and it's also not the best to support multiple databases.
• Associations with default attributes #18 I set up a has_many through association, and it just worked!!! I also added support for users.with to set default and derivable attributes. Check the PR for the comment on our bananas Struct use.
• Forgot to test that default attributes can be overriden #19 following up on that, I added an extra test, I remembered as soon as I merged Associations with default attributes #18.

Up Next

Next week, I'd like to set up a geminabox server on Heroku to host the gem so you can start using it in your apps. Have any of you worked with this before?

I've been meaning to do a write up on using GitHub better to follow along with this repo, and the tips are useful for building context in any repo.

@manuraj17 brought up namespaces, e.g. what happens to register Post::Comment, which I haven't really thought about yet. I'm going to be looking into having some sort of namespace conventions, maybe posts.comments.update :first, post: posts.first, subject: "My Insightful Critique, Vol. I", body: "In this Essay I will…"

I want to look at using upsert in our Active Record calls (right now we're doing find_by + update or create), because that would let us cache the fixture files in SQL and be able to just seed the database with that. It's probably pretty tricky to do reliably, so this is going to be a relatively long process to figure out whether or not that's viable.

Setting up a Zoom/Whereby call to discuss where we're at, and hear your ideas. I'm curious if y'all are interested in doing a call? I could walk through the current codebase, and then we can see whatever else pops up. I'm thinking Thursday at 6pm UTC+2, that should cover most of the time zones we've got. How does that sound?

Kind of a packed week, this may be a bit too ambitious, so we'll see.

Contributions

I'm hoping that getting the gem out so y'all can use it more will mean that the API is settled more so it'll make sense to start looking at README and documentation writing. I'm hopeful we can get to that during the week. I'll probably make an announcement with some documentation tips.

How's it working for you so far?

It seems like what's worked best for me for working on the code is to pick a few days in the week and then do some bursts of activity (and that may change as we go along), but how's that been for y'all to follow? Is it still relatively easy to follow along with what's been going on and be caught up? — are the recaps helpful in cutting through all that instead if the PRs are too much?

Anything you feel like is missing here, or that we should do differently? How do you like the code and how the API is looking so far?

[kaspth]

Forgot to mention I'm also thinking of looking at a conversion script for Fixtures files, e.g. this:

# test/fixtures/users.yml
kasper:
  name: "Kasper"

becomes:

# test/seeds/users.rb
users.update :kasper, name: "Kasper"

and so on. I've been meaning to test the inter-op between Rails' fixtures and our seeds so they can co-exist too. If anybody is interested in starting a PR for this, please do!

[BakiVernes]

@kaspth should we account for a nested fixture structure when creating this script or should we just go for a shallow conversion?

[kaspth]

@BakiVernes yes, I think a file like test/fixtures/posts/comments.yml should become test/seeds/posts/comments.rb.

[BakiVernes]

Ok, I'll work on a PR for this

[manuelfcreis]

https://github.com/kaspth/oaken/blob/main/lib/oaken.rb#L28-L37 looks really good! 🎉

Next week, I'd like to set up a geminabox server on Heroku to host the gem so you can start using it in your apps. Have any of you worked with this before?

Never worked with it, but it seems like a good way to do it.

I'm thinking Thursday at 6pm UTC+2, that should cover most of the time zones we've got. How does that sound?

This sounds great!

[kaspth]

https://github.com/kaspth/oaken/blob/main/lib/oaken.rb#L28-L37 looks really good! 🎉

Really cool to hear code callouts and what people find interesting, thank you!

Ok, I'll write up the call.

[manuraj17]

Setting up a Zoom/Whereby call to discuss where we're at, and hear your ideas. I'm curious if y'all are interested in doing a call? I could walk through the current codebase, and then we can see whatever else pops up. I'm thinking Thursday at 6pm UTC+2, that should cover most of the time zones we've got. How does that sound?

I must be one of the folks on extreme end of the timezone - if I suggest this to be 7pm UTC+2 will that work out for everyone? But, this would be a great idea.

Have any of you worked with this before?

Nope.

I've been meaning to do a write up on using GitHub better to follow along with this repo, and the tips are useful for building context in any repo.

This is a good idea as well 👍🏽

how's that been for y'all to follow?

It's fine to follow. May not be able to contribute immediately but good enough to catchup.

Is it still relatively easy to follow along with what's been going on and be caught up? — are the recaps helpful in cutting through all that instead if the PRs are too much?

Recaps are really helpful. Do continue this format.

[kaspth]

I must be one of the folks on extreme end of the timezone - if I suggest this to be 7pm UTC+2 will that work out for everyone? But, this would be a great idea.

7pm would actually fit me a bit better, so I'll set up the call for that. We can always do more too.

It's fine to follow. May not be able to contribute immediately but good enough to catchup.

Great!

Recaps are really helpful. Do continue this format.

I've been really liking them too! I had no idea when I started them how useful they'd be.

[codergeek121]

Next week, I'd like to set up a geminabox server on Heroku to host the gem so you can start using it in your apps. Have any of you worked with this before?

I have worked with geminabox, but have never set it up. I think it needs a persistent folder to store the gem, I'm not sure if that's easily possible with Heroku.
I'd be fine with a low-tech solution like path: '../oaken' and maybe a small guide on how to develop locally? I can try to add a small section to the README.

I want to look at using upsert in our Active Record calls (right now we're doing find_by + update or create), because that would let us cache the fixture files in SQL and be able to just seed the database with that. It's probably pretty tricky to do reliably, so this is going to be a relatively long process to figure out whether or not that's viable.

I think a gotcha everybody stumbles upon when using fixtures instead of factorybot, is that factorybot executes Callbacks and Fixtures do not. I guess with upsert we would not execute Callbacks anymore, so it would be a pretty significant decision. I've got two random thoughts that I'll add but have not formed an opinion about, I'd interested in hearing all your opinions:

• Should we make executing callbacks configurable in some way? E.g. some records are upserted, some created with callbacks
• Using has_secure_password or similar code is a little bit awkward with fixtures, since we do have to think about the value of the column value in the fixture.

Setting up a Zoom/Whereby call to discuss where we're at, and hear your ideas. I'm curious if y'all are interested in doing a call? I could walk through the current codebase, and then we can see whatever else pops up. I'm thinking Thursday at 6pm UTC+2, that should cover most of the time zones we've got. How does that sound?

I'll try to join, great idea.

How's it working for you so far?

It seems like what's worked best for me for working on the code is to pick a few days in the week and then do some bursts of activity (and that may change as we go along), but how's that been for y'all to follow? Is it still relatively easy to follow along with what's been going on and be caught up? — are the recaps helpful in cutting through all that instead if the PRs are too much?

The API changes in the recap are really helpful. I haven't had time to check out all PRs yet, but seeing the API changes helps a lot to keep up.

Anything you feel like is missing here, or that we should do differently? How do you like the code and how the API is looking so far?

I really like the async format and the api.

When catching up I had some issues to understand with the users.update(id, **args) signature/name, since it took me some time to understand that it's not the AR#update method. On the one hand it has a different signature, on the other hand at least in Rails codebases it's easy to confuse the two. Maybe that's just me though :)

Thank you so far.

[kaspth]

Great points all around here! I'm glad you brought up the callbacks and users.update signature on the call. I'm gonna review your #23 now and then let's see how that goes.