Support any column type for SQL.js?

[VinceOPS]

Hi there! We're using sql.js to run our unit tests against our code, and this is actually very convenient (as it allows us doing this even if PgSQL is not available/running on the machine). The best approach would actually be to mock the Connection and its repositories (instead of using an in-mem db), but I did not look for a clean way to do it yet...

However...

Issue type:

[ ] question
[ ] bug report
[x] feature request
[ ] documentation issue

Database system/driver:

[ ] cordova
[ ] mongodb
[ ] mssql
[ ] mysql / mariadb
[ ] oracle
[ ] postgres
[ ] sqlite
[x] sqljs
[ ] websql

TypeORM version:

[x] latest
[ ] @next
[ ] 0.x.x (or put your version here)

Steps to reproduce or a small repository showing the problem:

Connect to a database with type being "sql.js" and with entities containing an entity with a @column of type "timestamp".

We can see in many places that SQLite should be able to support any type (including timestamp, also here), as stated in the documentation of the v2),
If SQL.js is a port of SQLite, and SQLite is "typeless", should TypeORM accepts any type for the columns of the entities given to a sql.js database?

At the current time, this is what we get when running our unit tests:

DataTypeNotSupportedError: Data type "timestamp" in "EntityName.createdAt" is not supported by "sqljs" database.

Thanks for this beautiful project!

[pleerock]

@daniel-lang what do you think about it?

[VinceOPS]

Hi @pleerock!
Thanks for your interest in this issue.

Just to keep you posted, I started working on a proposal two days ago, using the same condition than this one in order to skip metadata validation for SqljsDriver... But it might be a too hard cut. Thus, I started implementing an optional option in the configuration of SqljsDriver, as a connection option, but it might be a too personal/custom change...

At the present time, I'd rather wait for your opinion before changing anything :). I tried mocking everything (connection, entity manager, etc) but it's a lot of boilerplate code and could not get something fully working. Thus, at the present time, we just keep running our unit tests against a real database (pgsql).

[pleerock]

Maybe its a better idea to create a separate driver type specially for testing purpose? Which can be based on sqljs

[VinceOPS]

That sounds great!

[pleerock]

@VinceOPS I think it would be great to have a page in our documentation about "How to do testing" with TypeORM, where we provide information about all user cases and what tools we provide to solve their testing problems. It can be a good start point for us to provide all necessary testing infrastructure for users if we start with list of problems user face when he write test for apps using typeorm.

[VinceOPS]

@pleerock

In this very specific case, this is about unit-testing a service handling our business logic. The service depends on a custom repository (which is injected using DI) and we want to tests the business code and spy the custom repository (make sure that proper methods are called when no error is thrown, for instance). However, creating a custom repository requires a valid connection to the database.
This is the most common case (for us) in unit testing, with or without a custom repository (sometimes the default one is enough). I can provide a code sample if required (NestJs project).

For the other most common case (e2e testing), I will personally always stick to my real database system.

[pleerock]

It would be great if someone can take initiative on this question and implement all the tools people need do easy and proper testing using typeorm for both e2e and unit testing.

We have similar discussion in #1267 and #171

[VinceOPS]

I'd be glad to help if a few directions are given. I'm pretty new to TypeORM but the code is clear and documented so this is not an issue.
Shall we create a dedicated module/repository as a library, or integrate the tools/classes in the existing codebase? Do you have any clues regarding the best approach to mock the connection and all its dependencies? If it helps a lot, would you be ready to add a few helpers/methods in the codebase (simple hypothesis)?

Thanks

[pleerock]

First we shall start with the list of all possible problems user face during writing unit/functional/e2e tests. Second we'll think what tools we shall provide to resolve those problems. Third we'll start implementation. First and second steps what we shall start with.

[pleerock]

Let's keep discussion in a single thread. Closing in favour of #1267.