SQLite returns timestamp for date fields defined by `t.datetime` in a populated entity about mikro-orm HOT 4 CLOSED

define property with @Property({ type: t.datetime }) or @Property({ type: DateTimeType }) (recommended in docs)

Where do you read it's "recommended"? I would actually discourage it, since it means the hydration will use the custom type convertor methods, resulting in a (small) perf hit. I would love to find a way around this, but some types need the convertors (and users can extend the type, in which case we also need to respect it).

edit: just to be clear, I would love to find a way around the perf issue, what you are reporting here is something we will surely find a fix for regardless of that

from mikro-orm.

By "recommended" I mean that I understood that types may be defined by t. constants:

There is also a types map (exported also as just t for brevity):

import { t } from '@mikro-orm/core'; // `t` or `types`

@Property({ type: t.text })
bio = '';

So that's why I'm using t.datetime for date and time type.

If you discourage it, what is the proper way of defining it?

Other ways ('datetime'|'Date'|Date) work fine, but I haven't seen these in docs, except Upgrading from v5 to v6 > Changes in Date property mapping

from mikro-orm.

Other ways ('datetime'|'Date'|Date) work fine

Any of those. When you use the types map, you use the custom type, which in fact does nothing (but the hydration functions still need to call its convertor methods, as it does not know they are in fact just identity functions).

If you are not using a union type (as in Date | null), you don't need anything, as the type will be inferred via reflect metadata. Equivalent to that is adding type: 'Date', but all the other variants should converge to the same - the problematic part is only when you use the type implementation.

Again, this is rather something to improve than to document, I don't want people to think about this.

from mikro-orm.

Thank you!

from mikro-orm.