Brann Joly

I ended up creating a migration like this : `npx mikro-orm migration:create --blank --name my_trigger` and I then referenced the migration class in a jsdoc comment: ``` javascript import {...

> Hmm, would be easy to add, but need a new cli option. > > They are shown and greyed since they are either indexed or considered foreign keys. Which...

> Well, the rational is more or less for not changing the current behaviour, sort of why it would be a new argument. Yes I undestand. I think the doc...

> I am planning something similar, joining things only for to-one relations, and using separate selects for to-many relations. This way the cartesian products won't explode. Such a strategy would...

> I see, I guess we could just batch those select calls, just like we do it with the insert/update queries from flush. We can do that easily now. I...

I did a quick example showing how much the "joined" strategy is broken using postgress when the number of collection grows. The repo is [here](https://github.com/BrannJoly/mikro-orm-bug-1) Here is what I do:...

> I did a quick test and it looks quite fast on my end, a query with `where in 10000 ids` takes around 20ms locally with postgres. I guess things...

> I wanted to see a repro where the select in strategy is slow, joining to-many relations is destined to be problematic due to the cartesian products, and your repro...

Same problem here! I also tried this : ``` javascript const trajectory = await plugin.builders.structure.parseTrajectory(data, 'sdf'); const hierarchy = await plugin.builders.structure.hierarchy.applyPreset(trajectory, 'default'); if (hierarchy) { await setSubtreeVisibility(plugin.state.data, hierarchy?.representation, false); await...