DenoDB

Post by TranquilMarmot » Sun, Jun 20, 2021, 4:41 PM UTC

dragonwriter wrote: post #177

TranquilMarmot wrote: post #175

Earlier quoted context omitted.

> devs started to get afraid of changing schema or code that touched database because that could create runtime errors as opposed to compilation errors. Being afraid to refactor is really bad and piles up quickly as technical debt Yes, this definitely happens! Like somebody else said, tests can cover a lot of this. But of course they aren't perfect. Where I'm at right now, we have multiple microservices reading from…

> Where I'm at right now, we have multiple microservices reading from the same database Like, all from the same base tables or each with their own schema with service-specific views? Also, isn't shared-DB integration by-definition incompatible with “microservices”, which are isolated and sovereign over their own data?

Post by spion » Mon, Jun 21, 2021, 12:34 PM UTC

dimitrios1 wrote: post #168

brainless wrote: post #134

Every time we discuss an ORM project, someone is bound to complain about ORMs in general. I have a small suggestion: please try ORMs in different languages. A lot of the power of an ORM depends on the language. Your ORM may not be the same as my ORMs - Django ORM, SQLAlchemy, Pony ORM. Try them and you will know why. I will wait. From my limited understanding, the language needs to allow reflecting and manipulating y…

Used ORMs in many different languages, from ActiveRecord, Hibernate, EntityFramework, SQLAlchemy, Bookshelf.js, GORM, and Ecto (Ecto was the best, ActiveRecord was the most "feature rich", Hibernate makes me cry, and EntityFramework is OK so long as you give Microsoft a lot of money). For dynamic languages the downsides are increased runtime cost over simply writing and executing sql and doing the mapping yourself, a…

Post by dimitrios1 » Mon, Jun 21, 2021, 1:53 PM UTC

spion wrote: post #213

dimitrios1 wrote: post #168

Earlier quoted context omitted.

Used ORMs in many different languages, from ActiveRecord, Hibernate, EntityFramework, SQLAlchemy, Bookshelf.js, GORM, and Ecto (Ecto was the best, ActiveRecord was the most "feature rich", Hibernate makes me cry, and EntityFramework is OK so long as you give Microsoft a lot of money). For dynamic languages the downsides are increased runtime cost over simply writing and executing sql and doing the mapping yourself, a…

I don't think EntityFramework Core (on NET Core) costs all that much?

Post by BenjieGillam » Tue, Jun 22, 2021, 7:17 AM UTC

SomeCallMeTim wrote: post #216

smt88 wrote: post #209

Earlier quoted context omitted.

I think you're highlighting features that are not inherent to ORMs but seem to be packaged with the ORM you use. There are libraries that will transform a Postgres or MySQL schema into a GraphQL API. I don't keep up with them, but the names Postgraphile and Hasura come to mind. I also think that you're saying that (Type)ORM is a good solution because it saves you a lot of time, but are you a typical user? Your case s…

I'm actually using Prisma.io right now. TypeORM has another similar solution. Postgraphile looks cool, but ... you're writing your custom handler in PostgreSQL script . This strikes me as suboptimal for debugging and general developer productivity. Otherwise, you're right, it's a similar solution. Which actually contradicts your assertion that I'm highlighting features "packaged with the ORM I use." Hasura...looks li…

Post by SomeCallMeTim » Wed, Jun 23, 2021, 2:07 AM UTC

saurik wrote: post #208

SomeCallMeTim wrote: post #207

Earlier quoted context omitted.

OK, that's awesome. But type safety is only part of the equation. Automatic CRUD or GraphQL code generation and/or other abstraction such that you never need to write basic CRUD code ever again? That should be a minimal software engineering best practice at this point, and yet we have tons of people insisting on writing every single query, either as a SQL query directly or using a query builder. It's on the order of…

I have read through a bunch of your comments and it frankly doesn't even sound like you are doing database queries for an application: it sounds like you were tasked with creating a very general purpose API endpoint for application developers. You thereby to me don't even seem to be having a use case for an "ORM", so I am extremely confused? It seems like you wanted a tool that let you describe an intended API surfac…

    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,
    });