Databases
380 verified issues
[FEATURE]: Support Polymorphic Association
Describe what you want I'm looking for a Typesafe ORM that support for polymorphic associations. To give a concrete example: I have a `Comment` model. I need this model to be associated with both `Article` and `Photo` models. Instead of creating separate tables or associations for comments on articles and comments on photos, I would prefer a unified approach where a single `Comment` can belong to either an `Article` or a `Photo`. Most ORMs (and query builders) except Prisma support polymorphic association. Prisma is not taking interest in solving this issue: https://github.com/prisma/prisma/issues/1644. If you plan on implementing Prisma, that would be a killer feature that would be a reason in itself to use Drizzle. A few teams have mentioned it explicitly in that issue. Do you plan to support and document this feature in the near future ?
Cannot set property EntityManager of #<Object> which has only a getter
Issue type: [x] bug report Database system/driver: [x] `postgres` TypeORM version: [x] `latest` Steps to reproduce or a small repository showing the problem: [code block] Somehow getting this random error now and have. Literally tried rolling back my code and everything. Any suggestions where to look?
Error: Cannot get entity metadata for the given alias
Issue type: [x] question [ ] bug report [ ] feature request [ ] documentation issue Database system/driver: [ ] `cordova` [ ] `mongodb` [ ] `mssql` [ ] `mysql` / `mariadb` [ ] `oracle` [x] `postgres` [ ] `cockroachdb` [ ] `sqlite` [ ] `sqljs` [ ] `react-native` [ ] `expo` TypeORM version: [x] `latest` [ ] `@next` [ ] `0.x.x` (or put your version here) Steps to reproduce or a small repository showing the problem: Hi. I'm having an issue with retrieving documents from a nested FROM-clause like this: [code block] And get the error `` Cannot get entity metadata for the given alias "alias". `` Also, if I try to add another from: [code block] the query works, but the second FROM doesn't replace the first one, as specified in the docs. How can I do this the right way? Thanks <!-- To answer those questions you need to put "x" inside the square brackets, for example: [x] `mysql` [ ] `postgres` Also, please format your code properly (by taking code blocks into [code block]) !>
[FEATURE]: Support PostgreSQL's Row Level Security (RLS)
Describe want to want Supabase is really nicely using Row Level Secruity for granular authorization rules. 🔗 Here's the link to their docs: https://supabase.com/docs/guides/auth/row-level-security I'd love to switch from Supabase JS SDK to drizzle based on all the features, but one limitation right now is that it seems it does not support row level secruity. Would love if you would consider adding this feature if also other users would find it helpful!
typeorm findOneBy( { id: null or undefined } ) method return the first record on the table !
Expected Behavior Return `null` Actual Behavior Retrieve the first record from users table ! Example : [code block] Steps to Reproduce 1. Create typeorm connection 2. Create user entity and migrate it to the database 3. Query the database using the user repository then call `findOneBy` method . Relevant Database Driver(s) | DB Type | Reproducible | |-------------------| --- | | `sqlite` | yes | For other database drivers , i have no idea :)
Generating migrations with cli
Issue Description Expected Behavior Migrations get generated using the cli Actual Behavior I am following the documentation outlined here https://typeorm.io/migrations and I feel like the documentation is way different then what is actually happening in the cli. I have tried just running the following command: `typeorm migration:generate -n PostRefactoring` When I run this command I get the following: `Not enough non-option arguments: got 0, need at least 1` So then I modify the command to something like this: `Missing required argument: dataSource` So then from there I add the datasource since that is what it is asking for: `npx typeorm migration:generate test -d app-data-source.ts` (I found the -d somewhere online while investigating this issue) But once I run that command I get the following error: `File must contain a TypeScript / JavaScript code and export a DataSource instance.` I have been trying to get this to work for days and I am about ready to throw the towl in and use a different ORM...which I don't want to do. I know that everything is working fine because I can start up the app and the app connects to the database and creates rows in the database. So it is just something with the cli and trying to generate the migrations. Here is what is in my app-data-source.ts file: [code block] This is the contents of my app.ts file: [code block] All these files were setup using the instructions outlined in the express typeorm documentation: Example with
How can I sort relations loaded with find's "relations" option?
Issue type: [X] question [ ] bug report [ ] feature request [ ] documentation issue Database system/driver: [ ] `cordova` [ ] `mongodb` [ ] `mssql` [ ] `mysql` / `mariadb` [ ] `oracle` [X] `postgres` [ ] `sqlite` [ ] `sqljs` [ ] `react-native` [ ] `expo` TypeORM version: [X] `latest` [ ] `@next` [ ] `0.x.x` (or put your version here) Steps to reproduce or a small repository showing the problem: I'm loading an entity with a one-to-many relationship. So, that relationship is an array of entities associated with the entity I'm querying. I'd like to specify an order for that array of entities. Example (Users and their Photos): I'd like to query a user, load their photos as a relation, and the photos should be loaded by their createdAt date: [code block] Is there a way to do this?
0.4.0 release TODOs
I'm going to keep writing here features and changes I'm planning to introduce in 0.4.0: - [x] (breaking) instead of named connections as they are right now, make it possible to write connections, managers and repositories into exported variables, e.g. `const connection1 = createConnection(); const connection2 = createConnection();`, `const manager1 = connection1.manager; const manager2 = connection2.manager;`, etc. - [ ] (breaking) we need to change some names in the project to make things more clear. `Connection` should be renamed to `Storage` and `QueryBuilder` should be renamed to `Connection`. - [x] (breaking) remove transaction decorator ? - [x] (breaking) remove custom repository functionality? - [ ] (breaking) deprecate eager and lazy loading? - [x] (breaking) re-work current configuration loading and ormconfig file concept - [ ] re-work entity schemas and make them "primary way of defining a database schema model" - [ ] re-work QueryBuilder concept - [ ] make subset of changes regarding to how joins are used right now to implement entity streaming - [ ] provide a tutorial on how it can be easy to integrate typeorm and graphql - [ ] check if typeorm can be used with knex and provide a tutorial if possible - [ ] transpile it to es6 and support only node 10 to improve performance and make it easier to debug typeorm-based apps - [ ] add flag in find options to log query per-find-call - [ ] remove some magic methods from QueryBuilder (like joinAndMap) - [ ] add `saveAndRe
browser: Can't resolve 'react-native-sqlite-storage'
Issue type: [ ] question [x] bug report [ ] feature request [ ] documentation issue Database system/driver: [ ] `cordova` [ ] `mongodb` [ ] `mssql` [ ] `mysql` / `mariadb` [ ] `oracle` [ ] `postgres` [ ] `sqlite` [x] `sqljs` [x] `react-native` TypeORM version: [x] `latest` [ ] `@next` [ ] `0.x.x` (or put your version here) Steps to reproduce or a small repository showing the problem: I followed the steps to use typeorm in the browser, including making the webpack changes. I end up with: [code block]
Make previous value available in @AfterUpdate function
By popular request, it would be very useful if we could also access the previous state of objects being updated in @AfterUpdate functions For example: [code block] Could become [code block] TypeORM already knows the previous value, as it will only call `@AfterUpdate` if it detects a change, therefore, the feature would only require that to be exposed to developer. Please see comment and thread - https://github.com/typeorm/typeorm/issues/1609#issuecomment-484303500 Thank you!
Support for `Json` field type in SQLite
Problem SQLite has had support for JSON field type for a while. `Sequelize` supports this field type on par with Postgres and MySQL. Lack of support for this field type by Prisma is preventing us from porting over our project. SQLite is a great bootstrapping technology that allows developers to quickly prototype applications without introducing new dependencies such as docker or worry about running yet another service in the development flow. JSON field type gives us the option to have a `nosql` database colocated in a `sql` database. Suggested solution Please implement support for this feature. See JSON ~~Extension~~ documentation and refer to `Sequelize`'s implementation if required. Alternatives Defer migration to Prisma and stick with `Sequelize`. Maintain status quo. Additional context cc: @ryands17 ref: https://github.com/prisma/prisma/discussions/3575
Be able to update or retrieve a single record including non-unique fields in the "where" conditions.
Problem I am unable to utilize non-unique fields in single update queries. To be clear, I want to still use the unique fields, I just want to filter it down even more. Suggested solution Here are my models [code block] I have "people" who have "clients" attached to them. Only the person who owns the client can update the name. So when an API call comes in, I know who the current person is and what client they're trying to update. So the update query I would like to use is this: [code block] but it only allows fields which are marked as `@unique` or `@id` Alternatives One alternative is to do a `.findUnique({ where: { id: input.clientId } })` and then check if the personId of the client is the same as the one passed in. This however creates two database calls where only one is needed. Another alternative is to do a `.updateMany({ where: { id: input.clientId, personId: input.personId } })` but I don't get any of the clients back. If I got the clients back in the query and if there was a `limit` I could pass in to limit it to one, I would feel better about this so it wouldn't have to do any unneeded scans of the rows, but it still feels less idiomatic than updating the `.update()` command to allow for non-unique fields.
Add support for PlanetScale serverless driver
Problem PlanetScale offers a serverless driver for environments like Cloudflare Workers and Deno Deploy, but Prisma does not have support for it. Suggested solution Adding a PlanetScale serverless driver to Prisma would solve this problem. I don't know the internals of Prisma, but PlanetScale's serverless driver is MySQL-compatible, just over HTTP. I imagine one could potentially reuse code from Prisma's existing MySQL driver to achieve this. Alternatives You could use the Prisma Data Proxy with PlanetScale, but it's an additional layer to jump through and adds an additional service to worry about.
[Proposal] Prisma Client Extensions
Client Extensions Proposal Hey folks, we started designing this feature and we’re ready to share our proposal. Please let us know what you think! Design We aim to provide you with a type-safe way to extend your Prisma Client to support many new use-cases and also give a way to express your creativity. We plan to work on four extension layers which are `$result`, `$model`, `$client`, `$use`. Let’s consider the following model: [code block] Computed fields We have this database model but we want to “augment” it at runtime. We want to add fields to our query results, have them computed at runtime, and let our own types flow through. To do this, we use `$result` to extend the results: [code block] We just extended our `User` model results with a new field called `fullName`. To do that, we defined our field with `compute`, where we expressed our field dependencies and computation logic. [code block] Result extensions will never over-fetch. It means that we only compute if we are able to: [code block] Finally, you will be able to add fields to all your model results at once via a generic call using `$all` instead of a model name: [code block] Results are never computed ahead of time, but only on access for performance reasons. Model methods Extending the results is useful, but we would also love to store some custom logic on our models too… so that we can encapsulate repetitive logic, or business logic. To do this, we want to use the new `$model` extension capabil
Segmentation fault crash when using prisma client when using PostgreSQL
Bug description When trying to use `findMany()` (or any other method) on a model, prisma client crashes and the following line appears in my log: `Segmentation fault (core dumped)`. This only happens if I use PostgreSQL as far as I know, this first appeared when I switched to PostgreSQL from mysql. How to reproduce 1. Initiate a new prisma project (make sure to use PostgreSQL) and generate the client - no errors there 2. Write a simple client which fetches some data from the databse 3. The script crashes and `Segmentation fault (core dumped)` gets logged in the console Expected behavior The script does not crash. Prisma information Example schema: [code block] Example test client: [code block] Environment & setup - OS: Pop!_OS (`Linux pop-os 5.15.5-76051505-generic #202111250933~1638201579~21.04~09f1aa7-Ubuntu SMP Tue Nov 30 02: x86_64 x86_64 x86_64 GNU/Linux`) - Database: PostgreSQL v14.1 (Ubuntu 14.1-1.pgdg21.04+1) - Node.js version: v17.2.0 Prisma Version [code block]
Feature: Soft Delete
I would like to know your opinion on implementing Soft Delete in TypeORM. I would love to help doing this.
Support ES6 modules export / ESM
It would be great if the Prisma Client JS generator would be compatible with ES6 modules out of the box. Note: Related to prisma/prisma-client-js#175
Use `JOIN`s in more queries
Problem Currently, there is no way to join tables together. Queries that include relations only include the relational data by using separate queries. Suggested solution I am hoping this can be implemented without a breaking API change. I would like to see a single query executed that joins multiple tables when necessary rather than a set of queries, each referencing a related table. Alternatives The only alternative I can see is to use raw queries.
Conditional uniqueness constraints; Partial/Filtered (Unique) Indexes
Problem I would like to be able to define a uniqueness constraint that has conditional elements to it so that it can map to and align with a conditional unique index/constraint within the database. Suggested solution Modify the `@@unique` modifier to include a `where: { }` argument that could define the condition that allows this to be unique.
Support for splitting Prisma schema into multiple files
Problem Prisma currently only supports one single Prisma Schema file. Developers want more flexibility for managing their Prisma Schema files. Motivations: breaking up large schema files to make them more manageable flexible integration with certain architectures, i.e. each module has its own self-contained logic including its schema Solution Support importing additional schema files, i.e. `import "user.schema"`, `import models/.prisma` or `import modules//.prisma`. Alternatives Not researched at this time. Additional context https://github.com/prisma/prisma/issues/92
Question: how to unit test without hitting the DB
I'm trying to write some unit tests of code that uses typeorm without hitting the DB. I'm using `getRepository` in the code to do stuff. In my tests ideally I'd like to call `getRepository(SomeEntity)` and then use sinon to `sinon.mock(repository).expects('find').withArgs(...).returns(stuff)`. To avoid hitting the DB I thought I'd just not call `createConnection` if I'm in the unit tests context. However I ran into the problem that `getRepository` calls connection manager which looks if it has a connection initialized and if not throws. What would be the recommended way of handling this? Is it possible to create a "dummy" connection somehow which doesn't try to connect anywhere?
Support for AWS Secrets Manager or Azure KeyVault in `schema.prisma`
Problem I'm using Prisma only to manage my database schema, not for the CRUD operations in code. The problem is that the schema.prisma file only supports defining the datasource URL using values defined in a file (dotenv). Since I don't want to store the database credentials in my project I'd like to obtain them from AWS Secrets Manager service. Suggested solution Provide a mechanism like a callback function to defined the datasource URL.
MongoDB support for Prisma 2+
Our team is considering working with Prisma, but as Prisma 1 seems to go out of scope and prisma 2 not mongo ready yet would love to know when is support expected to be released? a week? a month ? 2021 ?
Support querying across multiple schemas
Right now with Prisma, you can query across one schema at a time but in many cases, you need to query across multiple tables stored across multiple database schemas. We need to make certain product decision to enable this like how we are going to add this schema metadata information to the model and other implementation details that are necessary to be handled for this.
Make the MongoDB Replica Set Requirement Optional in Development
Problem MongoDB only allows you to start a transaction on a replica set. Prisma uses transactions internally to avoid partial writes on nested queries. This means we inherit the requirement of needing a replica set configured. This makes our getting started experience more cumbersome because a locally installed MongoDB doesn't have the replica set configured by default. If you try running Prisma against a MongoDB without a replica set, you get the following error: [code block] Suggested solution We should find a way to make this requirement optional, at least during development. In production, most people will host their MongoDB instance with the replica set configured. Alternatives Right now we recommend that you use MongoDB Atlas to launch a free instance that has replica set support out of the box. There's also an option to run the replica set locally with this guide: https://docs.mongodb.com/manual/tutorial/convert-standalone-to-replica-set/
Make cuid2 available in `@default`
Problem `cuid()` is deprecated now due to security reasons, can we let `cuid2` be an option when generating ids?
Subscriptions/real-time API support
Unfortunately at the current point of time Prisma 2 doesn't yet support subscriptions (real-time API features). Prisma 1 followed a different architecture which provided support for subscriptions. We might be planning to bring back real-time/subscriptions functionality in the future based on a standalone "events engine" (which will use CDC under the hood). This issue tracks the progress for this feature. Please feel free to share your specific requirements and wishes for this feature. 🙏
`createMany()` should return the created records
Initially brought up here: https://github.com/prisma/prisma/issues/4998#issuecomment-787206842 Problem The fact that the `createMany` API does not return the created records (which should be possible for Postgres) makes it difficult/impossible to use in some circumstances, meaning we must fall back to raw SQL. Here's an example. Let's say I have these two tables [code block] Let's say I want to create many posts and many comments. The data to be created could be represented like so: `Array<{post: PostData, comments: Array<CommentData>}>`. If `createMany` returned the created data, I could do something like this: [code block] However, since `createMany` does not return the created data, it is difficult to create many posts and then create many comments linked to those posts in an efficient manner. The remaining options are to create records one-by-one or use raw SQL. Using a combination of `createMany` and `findMany` is possible if you manually specify IDs, but does not work if you rely on Postgres (or some other DB) to generate IDs by default. Suggested solution `createMany` should return an array of created records (like how `create` returns the single created record). Alternatives Use `create` (inefficient if creating many records) Use raw SQL (efficient but inconvenient) * Use `createMany` + `findMany` (only works if you manually specify IDs, and also less efficient than if `createMany` returned created records) Additional context Personally, I've used raw
Support Oracle DB
Problem Support to Oracle db
[BUG]: jsonb always inserted as a json string when using postgres-js.
What version of `drizzle-orm` are you using? 0.26.5 What version of `drizzle-kit` are you using? 0.18.1 Describe the Bug Inserting an object into a postgres jsonb field with db.insert only inserts a string when using the postgres-js.adapter. Expected behavior With the pg package, an object is inserted using the code below, which is the expected behavior. With the postgres-js package, a string is inserted into the table using the same code. Environment & setup drizzle packages as above, and, "pg": "8.11.0" and "postgres": "3.3.5" schema.ts: import { pgTable, jsonb } from "drizzle-orm/pg-core"; export const logs = pgTable("log", { line: jsonb("line").$type<object>(), }); load.ts: let lines: { line: object }[] = []; let n = 0; for await (const line of rl) { const lineObj = JSON.parse(line); lines.push({ line: lineObj }); if (++n > numLines) { await runFunction(lines); lines = []; n = 0; } } await runFunction(lines); runFunction: async (lines) => { await db.insert(logs).values(lines); }