4 ms·
Good question! To which I respond with another question: Why not both? ;) Actual example code from my current project (with the actual object type anonymized b
by SomeCallMeTim 5y ago
Good question! To which I respond with another question: Why not both? ;)
Actual example code from my current project (with the actual object type anonymized by renaming it to "thing"):
const result = await prisma.thingInstance.findMany({
where: {
thingTypeId: {
in: thingTypes.map((id) => id.childThingTypeId),
},
thingInstanceChildren: {
none: {
parentThingId: {
equals: args.parentThingId,
},
},
},
},
orderBy: {
thingTypeId: "desc",
},
take: 120,
});
Returns an array of ThingInstance objects. It can also return joined relations (giving you the "Object Relational" part of ORM), or filter on joins, or what have you.
It's because Prisma (in this case) is an ORM that fully understands the data architecture that you can layer a full automation/code generation/GraphQL server on top of it. Not all ORMs have this feature, but you mostly need to start with an ORM in order to bootstrap this functionality.
I guess you could do what you're describing by creating tons of highly specialized code given a schema without adding the ORM/query building features--but adding the layer that gives you a Data Mapper pattern ORM is a tiny amount of additional effort at that point.
I did mention elsewhere: Some people seem to think that the ActiveRecord pattern is the only "ORM" approach, but Data Mapper is another approach--and one that is usually referred to as another view strategy of an ORM. [1]
[1] https://culttt.com/2014/06/18/whats-difference-active-record-data-mapper/ https://culttt.com/2014/06/18/whats-difference-active-record...