Generate Code Across Multiple Schema

[safaci2000]

Is your feature request related to a problem? Please describe.
Currently in order to use Jet across multiple schemas, you have to invoke it multiple times which is not great from a usability perspective, but also the code generated is unaware of the other schemas. There are also use cases where you may have a FKEY constraint pointing to a different schema that (may?) breaks code generation.

I'm currently blocked by 290 and can't confirm this but I assume there's issues in general simply because the introspection does not explore the full datamodel when invoked.

Describe the solution you'd like
I would like to be able to point to a list of schemas and tables ideally that are of interest and have Jet generate code for them.

[go-jet]

Yeah, jet generator only introspects single schema. I did a quick test with types from different schema (enum and foreign key) and it seems to work. The only thing noticed is that enum is of type string, but that can be fixed by customizing the generator.
I think we can add multiple schema support in some future release.

[safaci2000]

That would be amazing!

Looking forward to this missing feature being added!

[safaci2000]

I was wondering if had any thoughts when this would be picked up? While this is pending a proper fix, I was wondering what you thought about doing something like:

for schema in a b c ; do jet -dsn="postgres://ht_controller_user:secret@127.0.0.1:5432/funcap_controller?sslmode=disable"  -schema=$i -path=./.gen ; done;

Do you think that is safe enough assuming no table collisions? Though I'd prefer not to have to manage this myself there's enough that Jet provides that I'd love to use it. So doing something like:

SET search_path TO myschemaName;

prior to running the command should work I believe. Any thoughts?

[go-jet]

I think you misunderstood me. I don't see any meaningful issues with using Jet in a multi-schema environment. The only problem I encounter is that if an enum is used in a different schema from the schema where it is defined, it will appear in model types as a string. This can be easily overcome by simple type cast or customizing the generator.

Do you think that is safe enough assuming no table collisions? Though I'd prefer not to have to manage this myself there's enough that Jet provides that I'd love to use it.

There shouldn't be any collisions, because different schema will be generated in different folders.

So doing something like:
SET search_path TO myschemaName;
prior to running the command should work I believe. Any thoughts?

What's the goal of setting a search path. Are schema a, b and c completely different schema, or the same schema, but for different tenant?

[safaci2000]

Enum casting isn't an issue, though any references on custom generator would be great.

in my example, a,b,c and are different schemas. So what I was trying to get to, if the Generator runs and is aware that 3 schemas exists, then you could write the generator to discover the data types across the 3 namespaces and generate the correct go struct for it to use. If you're running the generator independently, then it doesn't have vision on the three schemas so it can only do the best it can with the information available, which I assume one behavior is the enum being cast to string as you pointed out.

I think the enum behavior is still a blocker for me to use it, so having a release at some point would be good (when you're ready to do so ), but if the folder division works, I can give this a go and see. The DSL of Jet is really appealing combined with the generated code based on a running database. <3

[houten11]

Enum casting isn't an issue, though any references on custom generator would be great.

https://github.com/go-jet/jet/wiki/Generator#generator-customization