Merge b2ed536 into 571efec

docs/docs/configuration.md

@@ -149,24 +149,6 @@ MikroORM.init({
 
 Read more about this in [Installation](installation.md) and [Read Connections](read-connections.md) sections.
 
-## Auto-flush
-
-Since MikroORM v3, default value for `autoFlush` is `false`. That means you need to call 
-`em.flush()` yourself to persist changes into database. You can still change this via ORM's 
-options to ease the transition but generally it is not recommended as it can cause unwanted 
-small transactions being created around each `persist`. 
-
-```typescript
-MikroORM.init({
-  autoFlush: true,
-});
-
-await orm.em.persist(new Entity()); // flushed
-orm.em.persist(new Entity(), false); // you can still use second parameter to disable auto-flushing
-```
-
-Read more about this in [Entity Manager](entity-manager.md#auto-flushing) docs.
-
 ## Naming Strategy
 
 When mapping your entities to database tables and columns, their names will be defined by naming 

docs/docs/entity-manager.md

@@ -8,10 +8,9 @@ sidebar_label: Entity Manager
 There are 2 methods we should first describe to understand how persisting works in MikroORM: 
 `em.persist()` and `em.flush()`.
 
-`em.persist(entity, flush?: boolean)` is used to mark new entities for future persisting. 
+`em.persist(entity)` is used to mark new entities for future persisting. 
 It will make the entity managed by given `EntityManager` and once `flush` will be called, it 
-will be written to the database. Second boolean parameter can be used to invoke `flush` 
-immediately. Its default value is configurable via `autoFlush` option.
+will be written to the database. 
 
 To understand `flush`, lets first define what managed entity is: An entity is managed if 
 it’s fetched from the database (via `em.find()`, `em.findOne()` or via other managed entity) 
@@ -60,19 +59,6 @@ orm.em.persistLater(book3);
 await orm.em.flush(); // flush everything to database at once
 ```
 
-### Auto-flushing
-
-Since MikroORM v3, default value for `autoFlush` is `false`. That means you need to call 
-`em.flush()` yourself to persist changes into database. You can still change this via ORM's
-options to ease the transition but generally it is not recommended as it can cause unwanted
-small transactions being created around each `persist`. 
-
-```typescript
-orm.em.persist(new Entity()); // no auto-flushing by default
-await orm.em.flush();
-await orm.em.persist(new Entity(), true); // you can still use second parameter to auto-flush
-```
-
 ## Fetching Entities with EntityManager
 
 To fetch entities from database you can use `find()` and `findOne()` of `EntityManager`: 
@@ -353,18 +339,17 @@ Gets count of entities matching the `where` condition.
 
 ---
 
-#### `persist(entity: AnyEntity | AnyEntity[], flush?: boolean): void | Promise<void>`
+#### `persist(entity: AnyEntity | AnyEntity[]): EntityManager`
 
 Tells the EntityManager to make an instance managed and persistent. The entity will be 
 entered into the database at or before transaction commit or as a result of the flush 
-operation. You can control immediate flushing via `flush` parameter and via `autoFlush`
-configuration option. 
+operation.
 
 ---
 
 #### `persistAndFlush(entity: AnyEntity | AnyEntity[]): Promise<void>`
 
-Shortcut for `persist` & `flush`.
+Shortcut for `persist` & `flush`. Same as `em.persist(entity).flush()`.
 
 ---
 
@@ -380,34 +365,24 @@ Flushes all changes to objects that have been queued up to now to the database.
 
 ---
 
-#### `remove(entityName: string | EntityClass<T>, where: AnyEntity | FilterQuery<T> | IPrimaryKey, flush?: boolean): Promise<number>`
-
-When provided entity instance as `where` value, then it calls `removeEntity(entity, flush)`, 
-otherwise it fires delete query with given `where` condition. 
-
-This method fires `beforeDelete` and `afterDelete` hooks only if you provide entity instance.  
-
----
-
-#### `removeEntity(entity: AnyEntity, flush?: boolean): Promise<number>`
+#### `remove(entity: AnyEntity): EntityManager`
 
 Removes an entity instance. A removed entity will be removed from the database at or before 
-transaction commit or as a result of the flush operation. You can control immediate flushing 
-via `flush` parameter and via `autoFlush` configuration option.
+transaction commit or as a result of the flush operation. 
 
 This method fires `beforeDelete` and `afterDelete` hooks.  
 
 ---
 
 #### `removeAndFlush(entity: AnyEntity): Promise<void>`
 
-Shortcut for `removeEntity` & `flush`.
+Shortcut for `remove` & `flush`. Same as `em.remove(entity).flush()`.
 
 ---
 
 #### `removeLater(entity: AnyEntity): void`
 
-Shortcut for `removeEntity` without flushing. 
+Shortcut for `remove` without flushing. 
 
 ---
 

docs/docs/repositories.md

@@ -143,12 +143,11 @@ Gets count of entities matching the `where` condition.
 
 ---
 
-#### `persist(entity: AnyEntity | AnyEntity[], flush?: boolean): Promise<void>`
+#### `persist(entity: AnyEntity | AnyEntity[]): Promise<void>`
 
 Tells the EntityManager to make an instance managed and persistent. The entity will be 
 entered into the database at or before transaction commit or as a result of the flush 
-operation. You can control immediate flushing via `flush` parameter and via `autoFlush`
-configuration option. 
+operation. 
 
 ---
 
@@ -160,7 +159,7 @@ Shortcut for `persist` & `flush`.
 
 #### `persistLater(entity: AnyEntity | AnyEntity[]): void`
 
-Shortcut for just `persist`, without flushing. 
+Shortcut for just `persist`, without flushing. Deprecated, use `em.persist()`.
 
 ---
 
@@ -170,7 +169,7 @@ Flushes all changes to objects that have been queued up to now to the database.
 
 ---
 
-#### `remove(where: AnyEntity | FilterQuery<T>, flush?: boolean): Promise<number>`
+#### `remove(where: AnyEntity | Reference<AnyEntity> | (AnyEntity | Reference<AnyEntity>)[]): Promise<void>`
 
 When provided entity instance as `where` value, then it calls `removeEntity(entity, flush)`, 
 otherwise it fires delete query with given `where` condition. 
@@ -181,15 +180,15 @@ This method fires `beforeDelete` and `afterDelete` hooks only if you provide ent
 
 #### `removeAndFlush(entity: AnyEntity): Promise<void>`
 
-Shortcut for `removeEntity` & `flush`.
+Shortcut for `remove` & `flush`.
 
 This method fires `beforeDelete` and `afterDelete` hooks. 
 
 ---
 
 #### `removeLater(entity: AnyEntity): void`
 
-Shortcut for `removeEntity` without flushing. 
+Shortcut for `remove` without flushing. Deprecated, use `em.remove()`.
 
 This method fires `beforeDelete` and `afterDelete` hooks. 
 

docs/docs/unit-of-work.md

@@ -100,29 +100,5 @@ await em.persistAndFlush(user);
 You can find more information about transactions in [Transactions and concurrency](transactions.md) 
 page.
 
-### Beware: Auto-flushing and Transactions
-
-> Since MikroORM v3, default value for `autoFlush` is `false`. That means you need to call 
-> `em.flush()` yourself to persist changes into database. You can still change this via ORM's
-> options to ease the transition but generally it is not recommended. 
-
-Originally there was only `em.persist(entity, flush = true)` method, that was
-automatically flushing changes to database, if not given second `false` parameter. This 
-behaviour can be now changed via `autoFlush` option when initializing the ORM:
-
-```typescript
-const orm = await MikroORM.init({
-  autoFlush: false, // defaults to false in v3, was true in v2
-  // ...
-});
-orm.em.persist(new Entity()); // no auto-flushing now
-await orm.em.flush();
-await orm.em.persist(new Entity(), true); // you can still use second parameter to auto-flush
-```
-
-When using driver that supports transactions (all SQL drivers), you should either keep auto-flushing 
-disabled, or use `persistLater()` method instead, as otherwise each `persist()` call will immediately 
-create new transaction to run the query.
-
 > This part of documentation is highly inspired by [doctrine internals docs](https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/unitofwork.html)
 > as the behaviour here is pretty much the same.

docs/docs/upgrading-v3-to-v4.md

@@ -72,6 +72,41 @@ Instead of interface merging with `WrappedEntity`, one can now use classic inher
 by extending `BaseEntity` exported from `@mikro-orm/core`. If you do so, `wrap(entity)` 
 will return your entity. 
 
+## Removed `flush` parameter from `persist()` and `remove()` methods
+
+`persist()` and `remove()` are now sync methods that only mark the entity for 
+persistence or removal. They now return the `EntityManager` to allow fluid flushing:
+
+```typescript
+// before
+await em.persist(jon, true);
+await em.remove(Author, jon, true);
+
+// after
+await em.persist(jon).flush();
+await em.remove(jon).flush();
+```
+
+## `remove()` method requires entity instances
+
+The `em.remove()` method originally allowed to pass either entity instance, or 
+a condition. When one passed a condition, it was firing a native delete query, 
+without handling transactions or hooks. 
+
+In v4, the method is now simplified and works only with entity instances. Use 
+`em.nativeDelete()` explicitly if you want to fire a delete query instead of 
+letting the `UnitOfWork` doing its job.
+
+```typescript
+// before
+await em.remove(Author, 1); // fires query directly
+
+// after 
+await em.nativeDelete(Author, 1);
+```
+
+> `em.removeEntity()` has been removed in favour of `em.remove()` (that now has almost the same signature).
+
 ## Custom types are now type safe
 
 Generic `Type` class has now two type arguments - the input and output types. 

docs/docs/usage-with-nestjs.md

@@ -36,7 +36,6 @@ create the request context for you automatically.
       entitiesDirsTs: ['src/entities'],
       dbName: 'my-db-name.sqlite3',
       type: 'sqlite',
-      autoFlush: false, // read more here: https://mikro-orm.io/unit-of-work/
     }),
     // ... your feature modules
   ],