Feature: In factory *Func() mods, having a way to know which factory type we're being called from

[jessdwitch]

When you call a *Func() mod like IDFunc(), it'd be nice to know if the caller is a Build(), BuildMany(), BuildSetter() or BuildManySetter(). I think the straightforward way to do this would be to pass in an enum, like FactoryType:

type FactoryType int

const (
	FactoryBuild = iota
	FactoryBuildMany
	...
)

and then the *Func functions become: *Func(func(FactoryType) T), e.g. IDFunc(func(FactoryType) int32)

There's at least 2 scenarios this could be useful for:

• In the case of Manys, you'd be able to create sequences, like incremented IDs (you'd have to track the index outside of the function, but I think generally for unit testing, you'd want to keep that at the test level anyway for use in assertions).
• For nested models where the you need to create the child in the middle of a service function, there's currently no way to have the ID unset for BuildSetter() but have it set to a non-0 value when you call Build() without having to create the object, store it, then modify it, which feels like it defeats the purpose of having a factory.

Edit: I goofed midway down and said Build when I meant Func, sorry!

[stephenafamo]

• For nested models where the you need to create the child in the middle of a service function, there's currently no way to have the ID unset for BuildSetter() but have it set to a non-0 value when you call Build() without having to create the object, store it, then modify it, which feels like it defeats the purpose of having a factory.

I'm not sure what you mean here. Can you share an example?

[jessdwitch]

Totally. So say you have a POST request body that looks something like:

{
    "parent": {
        "name": "bob",
        "child": {
            "name": "blorpo"
        }
}

I've got a DB model that looks like

CREATE TABLE people (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    child_id INTEGER REFERENCES people(id)
);

In my service function I need to create the child, and then the parent, so that I can populate parent's child_id. If I use a factory for this I currently have to do:

ctx := context.Background()
f := factory.New()
child := f.NewPerson(ctx, factory.PersonMods.Name("blorpo"))
childSet := child.BuildSetter() // Make the setter and store it without an ID
child.Apply(factory.PersonMods.ID(123)) // Set the ID separately from the initial factory call
childReturn := child.Build() // Now store the final model

parent := f.NewPerson(ctx,
  factory.PersonMods.Name("bob"),
  factory.PersonMods.ChildID(null.From[int32](childReturn.ID))
)

// Using a gomock repo as an example since that's what I'm testing with
repo.EXPECT().CreatePerson(ctx, childSet).Return(childReturn, nil)

repo.EXPECT().CreatePerson(ctx, parent.BuildSetter())

// assertions...

I'd rather do something like

child := f.NewPerson(ctx,
  factory.PersonMods.Name("blorpo"),
  factory.PersonMods.IDFunc(func(t FactoryType) null.Val[int32]) {
    if t == FactoryTypeBuild {
      return nullFrom[int32](456)
    }
    return nil
  }),
)

// etc

Or possibly even

child := f.NewPerson(ctx,
  factory.PersonMods.Name("blorpo"),
   // Leaves field nil on Setter, but populates field on Build. Simulating fields that would be set by a repo layer
  factory.PersonMods.IDOnBuild(null.From[int32](456)),
)

I like the second style more for my particular purposes, since it's more succinct, but the first one feels like it'd have uses outside the specific situation of trying to simulate a repo layer setting a field on create/update.

I made up this example to be simpler than the real thing, but if you look at the code I included in my previous ticket (#439), you can see how the same situation comes up with an event Trigger, where I need to create a child EventListener and that listener has a child ListenerType. When you nest another layer, this pattern gets really verbose.

(I think this is maybe evidence for Fact/Dim style schemas being a pain to work with generally, but I'm just working with what I inherited lol)

[stephenafamo]

This parent-child ID setting is automatically taken care of when you use Create and not Build.

If there is a way to match these IDs in the Build methods, would this work for your use case without needing to know what the caller is?

[jessdwitch]

Ya, I'm realizing I did an XY problem. Ultimately what I'm trying to accomplish is being able to tell the factory to set a field on Build, but leave it nil on BuildSetter (in the same way it already does for relationships, but for normal fields).

Another scenario that's even simpler and avoids the whole parent-child dynamic would be timestamps for e.g. created_at, updated_at. You'd want these to be nil in the Setter, but set in Build because a real application would probably have them populated by the DB.

So ya, I don't actually need to know what the caller is. I was just trying to come up with a way to accomplish what I described above, *Func seemed like the way to do it, and I got hung up on that, but the simple version of the request is just "I'd like to be able to configure the factory to populate a field with a value on Build that it leaves nil on BuildSetter"

[stephenafamo]

I'll give this some thought and let you know .

In the meantime, for your testing, is it possible to test it against the DB and use Create to make the models instead?

[jessdwitch]

I'm testing the API/service layer and using a mock for the DB's repository, so no. What I'm describing is still doable with bob, just with the aforementioned boilerplate of pre-making the setters and storing them in variables, then using apply, then storing the Build products. So I'm not blocked, it's just a pain. Thank you for considering it!