Martin Adámek

Hmm fixing this actually feels a tiny bit breaking, since now we only define the last relation from the list of duplicities, if I add the suffix, they will change...

Why not just `char` when you have that alias for the same already (and that is actually a recognized column type)?

> Why pick "string" for the types map instead of "varchar"? 😄 `string` is a runtime JS type, we need to map it to something. Unlike your proposal which came...

> meaning the only way to actually use MSSQL's "varchar" is with {columnType: 'varchar(255)'} Just like the only way to use `timestamp` instead of `timestamptz` in postgres is via `columnType`....

> But this is inconsistent Which part is inconsistent? > and only gets worse with "char" in the mix, where {type: 'char'} would be equivalent to {columnType: 'nchar'}, and to...

A workaround for your repro would be using `em.populate`, which will adjust the `user` entity populate hint internally and that is the main source when serializing now. The `_populated` flag...

Why don't you check the query yourself? It should be equivalent (it's actually a better approach in general).

you can't do that with `em.populate`, that only loads complete collections. i think i have a workaround for you, you could use `setSerializationContext` private method of EntityLoader, that is what...

I found a way to make this work automatically, under the hood it uses the `setSerializationContext` which is now also available via `wrap(entity).setSerializationContext()` and that one accepts the same options...

> I managed to work it out: You shouldn't need that explicit `setSerializationContext` call, it's done automatically in this case. > Onenote, it doesn't work on something like this wrap(users[0].groups).set....,...