prisma-client-go icon indicating copy to clipboard operation
prisma-client-go copied to clipboard

Run prisma-client-go generator standalone?

Open halostatue opened this issue 2 years ago • 5 comments

We are using Prisma in a cross-platform for schema definitions in a cross-platform non-JS environment, and want to add Go to our generated client output, but the way that prisma-client-go wants to be used does not work with our needs. These are slightly unusual. We are:

  • creating prisma schema fragments that describe the model we need for a particular data transfer package;
  • and combining these schema fragments with a common schema fragment and adding extra code to:
    • generate an ER diagram (with prisma-generator-erd);
    • generate a sample SQLite file (to get the structure for testing);
    • generate Elixir client code (as our file definitions are currently complete, this has been suspended until we can fork and improve the current Elixir client generator)

We are working with schema fragments because of prisma/prisma#2377.

We currently manage these within our Elixir code tree, but may move these to a separate repo. Because of the common file definitions and such, it does not make sense for us to have a separate copy of the generated prisma schema files in a Golang tree, but instead want to basically do something like prisma-client-go generate schema/generated/foo.prisma (where generated/foo.prisma is our combined output) and where the generated go files would be written to go/foo/... (we see no output configuration for the go generator).

Since we’re using a script to merge the schema fragments, when we look at enabling go generation, we could create go/foo, run go mod init && go get github.com/steebchen/prisma-client-go in it, and then copy the foo.prisma into it in order to run go run github.com/steebchen/prisma-client-go generate…but that feels really inelegant.

Is there a way to run prisma-client-go such that it will just generate the go code in the assumption that another repository has already accomplished this so that we can merely do a merge? Our .prisma files are intermediary artefacts, not primary sources the way it would be for a typical Prisma project.

halostatue avatar Aug 16 '23 15:08 halostatue

To be honest, I'm not really sure what your question is.

You can define both input prisma schema file:

go run github.com/steebchen/prisma-client-go generate --schema schema/generated/foo.prisma

and define the package output (just the directory at this time though) via your schema.prisma:

generator db {
  provider = "go run github.com/steebchen/prisma-client-go"
  output   = "./go/foo/"
}

This will generate ./go/foo/db_gen.go

steebchen avatar Aug 16 '23 20:08 steebchen

go run … fails if you have not already run go mod init && go get …. We’re not in a Go project when we do the code generation, but want to be able to maintain the schema independently (since it is shared by multiple implementations) and generate the code to merge into the projects as appropriate.

It looks like part of what we’re doing is feasible. I’m wondering if it is possible to do something like go install github.com/steebchen/prisma-client-go and run the generator outside of a properly initialized Go project.

halostatue avatar Aug 16 '23 20:08 halostatue

Ah gotcha. Yeah, I think your best bet is to do go install github.com/steebchen/prisma-client-go@latest once and just use the binary prisma-client-go. You should also be able to specify prisma-client-go in your Prisma schema instead of go run ... so that you can use prisma-client-go universally. You would just need to make sure to got the same version installed as the Prisma runtime to ensure consistency, but other than that I don't see anything wrong with the approach. Let me know if this answers your question!

steebchen avatar Aug 16 '23 20:08 steebchen

That worked, after a fashion. I’m not sure what the go/query-engine-darwin-arm64_gen.go is, and we're likely to have issues with the embedding of the schema file (the datasource is not necessarily the production datasource filename; in fact, because it’s sqlite, we are likely to have different filenames for different versions and may need to open multiple versions at the same time).

We will probably have other questions as we go along, but this is enough to get us started to determine if this is what we need.

Thanks!

halostatue avatar Aug 16 '23 21:08 halostatue

The go/query-engine-darwin-arm64_gen.go contains the Prisma query engine, you don't really have to care about that as it should just work. Once you do go build it is automatically included. If you deploy to a different OS/arch, you might need to specify binary engines explicitly, but you'll get an error if you do need to do that.

Feel free to join the free discord for quicker turnaround: https://goprisma.org/docs/community

steebchen avatar Aug 16 '23 23:08 steebchen