External relationships

[absolutejam]

I'm sorry for the influx of questions - I'm happy to add a PR to add what I've asked to the docs if it helps other people in the future 🙏

Currently, I have different 'domains' in a monolith, but many of the DB tables in each domain reference my apps's 'core' tables via. FK relationships.

I've split generation out so that each separate domain generates its own models, views, etc. by just running migrations for the tables I need. However, I noticed that the references back to the core tables wren't generated (because the core tables don't exist).

If I instead run all my 'core' migrations as well as the domain's migration, it instead generates new instances of my core tables's models, views, and all of the other helpers. I also tried excluding the tables with except but they are always generated (Which I can understand as they're referenced by another table/model).

For example, if I have an accounts table in my core, and then reference this via. a FK relationship, each domain gets its own copy of Account struct (and all of the other generated helpers).

Instead, I wonder if it would be possible to declare an external relationship, similar to how the types section works in bobgen.yml, so that we can choose an import path instead of generating new models. I believe this would still work as all of the child properties are provided by the child model/table/view, and missing models would be detected at compile-time.

As an aside, I'm using the SQLite plugin directly because my migrations are using goose and due to the format of the SQL file, if I use the SQL files plugin, I end up with no tables, eg.

-- +goose Up
CREATE TABLE ...

-- +goose Down
DROP TABLE ...

[stephenafamo]

Instead, I wonder if it would be possible to declare an external relationship, similar to how the types section works in bobgen.yml, so that we can choose an import path instead of generating new models. I believe this would still work as all of the child properties are provided by the child model/table/view, and missing models would be detected at compile-time.

If I understand correctly, you want to reference "externally generated models".
Can you give an example of how this would look? I kind of get it, but it isn't completely clear.

I also tried excluding the tables with except but they are always generated (Which I can understand as they're referenced by another table/model).

This is likely a bug. Can you raise an issue with a minimal reproduction?

If I instead run all my 'core' migrations as well as the domain's migration, it instead generates new instances of my core tables's models, views, and all of the other helpers.

At the moment, this may be the best thing to do.
If you ever need to convert between instances of a core table, since they are the same shape, I think you should be able to do domain1.Accounts(domain2Acct).

[absolutejam]

If I understand correctly, you want to reference "externally generated models".
Can you give an example of how this would look? I kind of get it, but it isn't completely clear.

I think it would just need to inhibit generation of an 'external model'.

sql:
  external:
    "Account": # Generated type name, or perhaps table name?
      package: "accounts"
      imports:
        - '"github.com/foo/bar/core/accounts"'

And this would inhibit generation of accounts.bob.go and instead just add the import statement and fully-qualify references to Account with accounts.Account.

For the time-being, I'm just using the duplicated types because I actually convert from the bob models to my own models in my repository, so the duplication doesn't harm me right now. But I'm considering directly using Bob generated types down the line.

I also tried excluding the tables with except but they are always generated (Which I can understand as they're referenced by another table/model).

Will see if I can throw this together tomorrow :)

[stephenafamo]

And this would inhibit generation of accounts.bob.go and instead just add the import statement and fully-qualify references to Account with accounts.Account.

This could work, although to prevent too many changes to the code generation (having to qualify everywhere), perhaps simply using aliases would work

// accounts.bob.go

type Account = core.Account
var Accounts = core.Accounts

[stephenafamo]

As an aside, I'm using the SQLite plugin directly because my migrations are using goose and due to the format of the SQL file, if I use the SQL files plugin

It is likely possible to write a generator using Bob and goose. You can take bobgen-sql/main.go as a base and switch the migrator to use Goose instead.

[absolutejam]

Will take a look at this, thanks!