Make ids optionals

[kaspth]

• Allow marking an alternate attribute as the unique key, like a name/title. Otherwise update's find_by can't find and upsert will only ever insert.

[kaspth]

Blegh, this is turning into a bit of a mess. Our whole structure is based on having ids to detect clashes, so it's a bit of mental leap for me to figure this out.

[tcannonfodder]

Brainstorming; would either of these 2 ideas help?

• An unkeyed_file! method at the top of a file. This would say "for everything I'm creating in this file, don't worry about IDs or clash detection."
  • If I’m creating data for an associations table, making IDs is a burden (one of the common problems with fixtures)
  • If I’m creating a slew of data to test performance, I likely don’t care about individual records
• Breaking up the creation actions into keyed/unkeyed counterparts. That way you don't have to try to force 2 different structures into the same set of APIs

[kaspth]

An unkeyed_file! method at the top of a file. This would say "for everything I'm creating in this file, don't worry about IDs or clash detection."

I've been trying to figure out what it looks like we add create/insert calls too for this kind of stuff.

If I’m creating data for an associations table, making IDs is a burden (one of the common problems with fixtures)

True, though I'm curious if we should try to detect clashes though? Maybe I'm getting way ahead of myself and we should actually just support create/insert for starters and provide caching (have I seeded or not with this checksum?) for that up front. Then we can figure out how update/upsert fits and if we can make the updates more granular.

If I’m creating a slew of data to test performance, I likely don’t care about individual records

I've been thinking about a kinda of users.fill_in API for this. I also saw this the other day and thought that was really interesting! https://github.com/Shopify/yjit-bench/blob/81efb0b3853e105b0b5ffec23847992de8961e5a/benchmarks/lobsters/lib/tasks/fake_data.rake

Breaking up the creation actions into keyed/unkeyed counterparts. That way you don't have to try to force 2 different structures into the same set of APIs

Ooooh yes, I'll try something like this! Thank you for the brainstorming 😄