Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/mikro-orm/mikro-orm/issues/1226 below:

Entities created by mikro's internals that also include private class fields throw an error · Issue #1226 · mikro-orm/mikro-orm · GitHub

Describe the bug

I started recently using mikro-orm in my projects, and it works beautifully (❤️), however I encountered an issue with an Entity that also uses private class fields (used to store variables that are unrelated to the data itself, but are needed for the structure). Thanks to @kyranet, we found the issue to be this line in EntityFactory

// creates new entity instance, bypassing constructor call as its already persisted entity
const entity = Object.create(meta.class.prototype);

This is fine for normal usage, and even for fields that are soft-privates (annotated with the private keyword in TS, but NOT using the # types of privates). I don't know if this is easy to solve, or if we should just not use private class fields with mikro-orm (something I don't directly mind, but would be a nice to have)

Stack trace

Encountered unexpected error: TypeError: Cannot write private member #client from an object whose class did not declare it
    at ScheduleEntity.setup (C:\Users\Vlad\Desktop\Development\TypeScript\TicketBot\dist\lib\schedule\ScheduleEntity.js:47:26)
    at ScheduleManager.init (C:\Users\Vlad\Desktop\Development\TypeScript\TicketBot\dist\lib\schedule\ScheduleManager.js:16:38)

To Reproduce
Steps to reproduce the behavior:

1. Create a simple entity with a private field

@Entity()
export class Example {
	@PrimaryKey()
	public id!: number;

	#myPrivateProp!: boolean;

	public setup(isAwesome: boolean) {
		this.#myPrivateProp = isAwesome;
	}
}

1. Attempt to construct it within your code, and persist it to the database

// This code sample will work just fine
const entry = new Example();
example.setup(true);

await em.persistAndFlush(entry);

1. Attempt to fetch an entity with a private class field, and try to read/write to the private properties

const fetchedEntry = await em.findOne({ id: 1 })!;

// This WILL throw, even though the `prototype` IS the "same"
fetchedEntry.setup(false);

Expected behavior
There should be no issues with creating such structures, however, due to the current way they're created (by bypassing the constructor), they become "shadow extensions" of the base class, and will throw.

Additional context

fetchedEntry instanceof Example -> true
fetchedEntry.__proto__ === Example -> fetchedEntry extends Example but isn't strictly an Example; this isn't Example, while this.__proto__ is

Versions

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4