From what I understand, Prisma currently doesn’t allow splitting the schema into multiple files and they’re moving fairly slow on this. For non-trivial projects, this is poor DX and makes the schema exploration as well as initial design pretty annoying.
Is there a way we can automate the Redwood side of the build system to merge multiple schema files into 1 prior to processing by Prisma? I realize a true fix would probably be more involved than just merging files so I’m mostly looking for some sort of optional and pragmatic middle ground.
Curious to hear your thoughts and possibly guidance on how such a feature can be done. If modifying Redwood is needed, I’m open to roll up my sleeves and help.
I’ve followed some threads on Prisma GitHub about this and something no one who has asked for this has been able to answer is: if I use a relation or type/enum that’s referenced in a different schema fragment file, is it worth losing the intelligence and autocomplete and validation that the Prisma extension offers? And how does one reconcile and handle if I accidentally add the enum or model more than once?
I’m curious what features would make it easier to explore your schema rather than having it in one file? Does the fact that it would be broken up file by model name give you an index or directory? So it’s a clear list of your models?
I ask because the Core team is working on some new dev tools and working with schema is something I’ve considered— but apart from a general list of models and or an erd, I’m wondering what else might be useful.
Any ideas? What might help you? Or would you like to have? Besides the multiple file import of course
Thank you for asking for this specific feedback. My most recent experience with webbev prior to react/node/Redwood was with Django and in the enterprise environment. So no doubt my expectation is primed by that background. There is a chance that the features I think I want may be the result of forcing the Django paradigm into the javascript world. I’m learning so if the feedback below seem off to you, I’d much appreciate feedback on the feedback
This is the first time I’m working on a nontrivial project with Redwood and Prisma. As the number of models pushed passed 15, I started to miss the following conveniences in addition to import:
Some form of interface or abstract base model support. That way common fields can be specified once and enforced on all implementation models. The obvious examples here would be createdAt, updatedAt
An optional but automated way to attach methods to a model so model-specific behaviors can be encapsulated.
An automated way to manage db triggers (checked into source code) so they don’t end up becoming orphaned, forgotten, and therefore dangerous in the rare situations where they may be needed.
Specifying relation with just 1 line, e.g. @relation(fields: [blogId], references: [id]) should be enough, the blogId field should be automatically injected. The @relation itself should specify n-ary so the relationship is immediately obvious at a glance for readers.
That’s all I can think of right now based on what I feel is missing during the past couple weeks of tinkering. Hope it helps.
I recently spent some time reading about TypeORM. At first glance, it seems to me to be more capable than Prisma. The obvious downsides are that their documentation game is nowhere near prisma, and they lack of a Prisma-studio equivalent.
However, the fact that their schema description language is Typescript itself does allow them to benefit from Typescript’s features, ecosystem tools, and editor plugins. Thus we can split up the model files in large projects for free, making separation of concerns a bit easier (specific aspects of a project can be packaged on its own, along with its models, components, to be included in the main project)
It looks like their relation definition is more explicitly spelled out as well, e.g. @OneToOne, @OneToMany, @ManyToOne. From my understanding of prisma so far, it seems there is a bit of cognitive distraction to identify these relationships from glancing at the code.
They even have several types of inheritance, including abstract inheritance so implemented models will get the same set of common columns for free.
I guess my reference points are the Django ORM and Hibernate, so I’m pretty excited about TypeORM because I see many features that I’ve come to know and love for a while. In this excitement, I may have missed the true strengths of Prisma. @dthyresson , I wonder if you can help me understand 2 things?
What were the main considerations to choose Prisma for RedwoodJS?
I’m tempted to try to swap Prisma for TypeORM in my Redwood project. How coupled is the rest of Redwood to Prisma? Do you think this is a significant undertaking?
Thank you so much and l’m really looking forward to your input on the matter!
Bumping this. @dthyresson I’d love to hear your feedback on this.
Also, I was thinking of RedwoodRecord too but couldn’t find resources beyond this RedwoodRecord | RedwoodJS Docs so I’m not certain the project is still being worked on.
I’m afraid this would be a pretty big task. Prisma and the prisma models/schema file is used by our generators and it’s integrated with graphql (typegen). That said, you’re not the first to be annoyed by Prisma, so a good look at alternatives would be welcome. Especially if you could share your findings in a way for us in the core team to quickly get a sense of the strengths and weaknesses of other options from a RW perspective.
Obviously biased, but Prisma vs TypeORM doesn’t make TypeORM look very appealing to me
It’s not actively being worked on right now. But if someone were to start using it and report bugs/issues I’m sure @rob would help fix whatever problems come up.
This is potentially gold. With this capability, one can get much closer to true separation of concerns. All models, components, and services of a concern can be placed in a separate package.
Ok. This feels interesting and needed enough that I would probably work on it at a slow pace. For the time being, I’d probably have to settle for workarounds and just accept the shortcomings.
IMO, the right approach is to have an abstraction layer that decouple Redwood from the underlying ORM. I’ll start with looking into the generator subsystem and as a first step, see if I can write an external generator based on TypeORM.
I have a problem with this extension. There seems to be a command not showing up in my VSC.
Extension description:
When you are done working on your schemas, you will need to merge them all into a single schema file and remove all import statements. To achieve this you can either
Just following up here in case someone wonders upon this. This is now supported as a “preview feature” by Prisma and Redwood. Check out details in the documentation here.
