PostgreSQL schemas for multitenancy #2074
Labels
enhancement
New feature or request
Milestone
Comments
B4nan
added a commit
that referenced
this issue
Oct 24, 2021
Closes #2074 BREAKING CHANGE: `em.getReference()` now has options parameter.
B4nan
added a commit
that referenced
this issue
Nov 6, 2021
Closes #2074 BREAKING CHANGE: `em.getReference()` now has options parameter.
B4nan
added a commit
that referenced
this issue
Nov 6, 2021
Closes #2074 BREAKING CHANGE: `em.getReference()` now has options parameter.
B4nan
added a commit
that referenced
this issue
Nov 6, 2021
Entity instances now hold schema name (as part of `WrappedEntity`). Managed entities will have the schema from `FindOptions` or metadata. Methods that create new entity instances like `em.create()` or `em.getReference()` now have an options parameter to allow setting the schema. We can also use `wrap(entity).setSchema()`.
Entities can now specify `@Entity({ schema: '*' })`, that way they will be ignored in `SchemaGenerator` unless `schema` option is specified.
- if we have schema specified on entity level, it only exists in that schema
- if we have * schema on entity, it can exist in any schema, always controlled by the parameter
- no schema on entity - default schema or from global orm config
Closes #2074
BREAKING CHANGE:
`em.getReference()` now has options parameter.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Hi, first of all, thank you very much for your huge work on this ORM. I am using it today in my libraries and I am very happy with it. However, I have a small problem with multi-tenancy via postgresql schemas. No problem to have something dynamic with FindOptions (on find methods), it works incredibly well, but when inserting/updating/deleting, it is not possible to specify a schema.
Describe the solution you'd like
I checked a little bit the code of your library, it would have been great if on
*flush()methods could take options, notably{schema: 'mytenant'}, andnativeInsert() / nativeUpdate() / nativeDelete()onAbstractSqlDriver, test beforeisPlatformSchemaAuthorized()or something like that.Maybe applying
withSchema(options.schema)on this line.I've already tried with a monkey patch (on my current projet node_modules folder... wooohooo) to specify a schema on queryBuilder at this line, and update/insert/delete with schema work like a charm.
I wish I could implement this with a PR to help but I'm too afraid to break whole parts of the library. If you did it on the Findable part but not on the insert etc., there must be a reason. If you give me a little help, I'll take a look. By the way, I will sponsor you in any case for your excellent work. This lib is much better than TypeORM and I'm already promoting it to my friends.
Describe alternatives you've considered
I've looked into creating a MikroORM instance (with the
nextversion) that allows you to take a schema in the initial configuration, then destroy the instance at the end of the request. I have the feeling that this is very heavy and I'm afraid that the number of connections to the database will explode and that it will slow down my application.Currently I'm thinking of adding isolation fields per client on each entity and using
@Filter()and compound indexes but it makes my upstream validations more complex, plus I'm not safe from missing something in my hooks (etc.) that may impact the data of another client.Additional context
Use on Postgresql and platforms that can support database schema, maybe dropping schemas on mongo ?
The text was updated successfully, but these errors were encountered: