Fix#1947

[emrahtoy]

This PR fixes 2 problem

1. type problem while calculating "a month ago", old code were return timestamp in numbers but it must be Date
2. Migrations to the uuid and timestamp with time zone Entity types with migration file

This PR adds 2 files

1. util file for getting data source to generate typeorm migrations
2. Migration file for type changes

This PR adds a npm command

1. in Server package "typeorm:migration-generate" added to have easier typeorm data source with the help of new utility file

[emrahtoy]

NOTE : This PR does not include Sqllite migration.

[HenryHengZJ]

coicidentally this PR also fixing the same issue

[HenryHengZJ]

@emrahtoy here's a list of supported types - https://orkhan.gitbook.io/typeorm/docs/entities#column-types

type uuid supports

• postgres
• mysql
• sqlite

type timestamp with time zone supports

• postgres
• mysql
• sqlite

I tested sqlite it seems to work, maybe because of the Init.ts migration script so it ignores the column types specified in entities. Have you tried on mysql?

[emrahtoy]

@emrahtoy here's a list of supported types - https://orkhan.gitbook.io/typeorm/docs/entities#column-types

type uuid supports

• postgres
• mysql
• sqlite

type timestamp with time zone supports

• postgres
• mysql
• sqlite

I tested sqlite it seems to work, maybe because of the Init.ts migration script so it ignores the column types specified in entities. Have you tried on mysql?

uuid becomes varchar find default that is why sqlite doesn't care about it.
timestamp with timezone type is not necessary as it is handled on the code side by returning actual date instead of numbers.

I haven't tested it on MySQL as it does not exist in my stack.

It seems like both PR are almost identical but mine has changed all the entities.

[HenryHengZJ]

@emrahtoy here's a list of supported types - https://orkhan.gitbook.io/typeorm/docs/entities#column-types
type uuid supports

• postgres
• mysql
• sqlite

type timestamp with time zone supports

• postgres
• mysql
• sqlite

I tested sqlite it seems to work, maybe because of the Init.ts migration script so it ignores the column types specified in entities. Have you tried on mysql?

uuid becomes varchar find default that is why sqlite doesn't care about it. timestamp with timezone type is not necessary as it is handled on the code side by returning actual date instead of numbers.

I haven't tested it on MySQL as it does not exist in my stack.

It seems like both PR are almost identical but mine has changed all the entities.

okay, in that case can we get rid of the timestamp with time zone as its not necessary and I'm afraid we will bump into issues supporting mysql.

[emrahtoy]

@emrahtoy here's a list of supported types - https://orkhan.gitbook.io/typeorm/docs/entities#column-types
type uuid supports

• postgres
• mysql
• sqlite

type timestamp with time zone supports

• postgres
• mysql
• sqlite

I tested sqlite it seems to work, maybe because of the Init.ts migration script so it ignores the column types specified in entities. Have you tried on mysql?

uuid becomes varchar find default that is why sqlite doesn't care about it. timestamp with timezone type is not necessary as it is handled on the code side by returning actual date instead of numbers.
I haven't tested it on MySQL as it does not exist in my stack.
It seems like both PR are almost identical but mine has changed all the entities.

okay, in that case can we get rid of the timestamp with time zone as its not necessary and I'm afraid we will bump into issues supporting mysql.

Yes for sure we can use timestamp

[emrahtoy]

I have just changed timestamp with timezone sections to timestamp

[HenryHengZJ]

@emrahtoy i dont think timestamp is supported for sqlite. Actually do we really need the column type there?

[emrahtoy]

@emrahtoy i dont think timestamp is supported for sqlite. Actually do we really need the column type there?

I believe giving a type is important. It gives the opportunity of being future proof.
Decorators has been handling different depending on the driver you pick ( MySQL, sqlite etc.. ) with this way TypeOrm know what to do with the value and does the necessary conversions.

Even if it doesn't give support at all we are still able to create our own custom handlers.

[HenryHengZJ]

thanks @emrahtoy !

[neliocaa]

when changing the table to uuid, whoever is upgrading receives an error, since they already have data in another format, especially when it comes externally,
So, changing the chatId and sessionId fields to uuid doesn't make sense, and causes a bug in the upgrade

[emrahtoy]

In my case, they were always UUID. @HenryHengZJ which one of these chatId and sessionId is actually a user variable?