Tsed: Date attribute being saved as double value in DB

[dsasidhar]

Informations

Type | Version
---|---
Bug/Question | 4.x

---

Description

The date saved by mongoose model is sometimes date object in mongodb on few machines and double. :

@Model({ name: "bookings" })
export class BookingModel {
  @Property() _id: string;
  @Property() name: string;

  @Property()
  @Ref(UserModel)
  client: Ref<UserModel>;

  @Property() contractDueDate: Date;

  @Property() depositAmount: number;

  @Property() depositDueDate: Date;

  @Default(Date.now())
  @Property()
  createdOn: Date;

  @Property() eventStartDate: Date;

  @Property() eventEndDate: Date;

}

My package.json looks as follow.

{
  "name": "project",
  "version": "1.0.0",
  "description": "",
  "main": "src/index.js",
  "author": "",
  "license": "MIT",
  "dependencies": {
    "@tsed/common": "^4.31.7",
    "@tsed/core": "^4.31.7",
    "@tsed/mongoose": "^4.31.7",
    "@tsed/swagger": "^4.31.7",
    "@tsed/testing": "^4.31.7",
    "@types/lodash": "^4.14.108",
    "aws-sdk": "^2.230.1",
    "axios": "^0.18.0",
    "bcryptjs": "^2.4.3",
    "body-parser": "^1.18.2",
    "body-parser-xml-json": "^1.0.0",
    "btoa": "^1.2.1",
    "compression": "^1.7.1",
    "concurrently": "^3.5.1",
    "connect-redis": "^3.3.3",
    "cookie-parser": "^1.4.3",
    "cors": "^2.8.4",
    "crypto": "^1.0.1",
    "email-templates": "^5.0.0",
    "express": "^4.16.3",
    "express-session": "^1.15.6",
    "helmet": "^3.12.0",
    "jsonwebtoken": "^8.2.1",
    "kue": "^0.11.6",
    "method-override": "^2.3.10",
    "moment": "^2.22.1",
    "moment-timezone": "^0.5.21",
    "mongoose": "^5.0.9",
    "nanoid": "^1.2.1",
    "node-fetch": "^2.1.2",
    "nodemailer": "^4.6.4",
    "nodemailer-ses-transport": "^1.5.1",
    "passport": "^0.4.0",
    "passport-local": "^1.0.0",
    "path": "^0.12.7",
    "prettier": "^1.12.1",
    "pug": "^2.0.3",
    "redis": "^2.8.0",
    "serve-static": "^1.13.1",
    "stripe": "^6.0.0",
    "swagger-ui-express": "^3.0.8",
    "uuid": "^3.2.1",
    "with-query": "1.0.2"
  },
  "devDependencies": {
    "@types/chai": "^4.1.2",
    "@types/chai-as-promised": "^7.1.0",
    "@types/cors": "^2.8.4",
    "@types/express": "^4.11.1",
    "@types/http-proxy": "^1.12.4",
    "@types/jsonwebtoken": "^7.2.6",
    "@types/mocha": "^2.2.48",
    "@types/mongoose": "^5.0.7",
    "@types/node": "^9.4.6",
    "@types/node-fetch": "^1.6.9",
    "@types/passport": "^0.4.3",
    "@types/request-promise": "^4.1.41",
    "@types/sinon": "^4.1.3",
    "@types/sinon-chai": "^2.7.29",
    "@types/supertest": "^2.0.4",
    "@types/swagger-schema-official": "^2.0.9",
    "@types/uuid": "^3.4.3",
    "chai": "^4.1.2",
    "chai-as-promised": "^7.1.1",
    "husky": "^0.14.3",
    "lint-staged": "^7.1.0",
    "mocha": "^5.0.0",
    "nodemon": "^1.14.12",
    "nyc": "^11.4.1",
    "rimraf": "^2.6.2",
    "safer-buffer": "^2.1.2",
    "sinon": "^4.2.2",
    "sinon-chai": "^2.14.0",
    "supertest": "^3.0.0",
    "ts-node": "^4.1.0",
    "tslint": "^5.9.1",
    "typescript": "^2.7.1"
  }
}

The only difference in yarn.lock between a system that stores date values correctly as dates and a system that stores as double values is the following line:
On a system that stores doubles:
qs@^6.4.0, qs@^6.5.2, qs@~6.5.2:
On a system that stores date values:
qs@^6.5.2, qs@~6.5.2:

I tried comparing db versions, mongoose versions and a lot of other things, but nothing proved of any consequence.

This has become a major hindrance in deploying the project, please help. I am unable to do date based queries because of this issue in faulty system.

[Romakita]

Hello @dsasidhar
You don't give enough information to help you and give the yarn-lock don't help at all. Based on your information, the problem probably come from querystring (qs) or mongoose/mongodb. So this issue isn't on the right repository XD.

But to determine where come from the problem, I can help you for that.

• What is the request sent to the server (data and method GET, POST, headers, etc...) where you have this issue.
• Add log in your controller to check the data deserialized by Ts.ED and compare the data stored on the request. Check dates deserialization.

Example:

@Controller('/')
class MyCtrl {

   @Get("/")
   get(@QueryParams() model: MyMongooseModel, @Req() request) {
      $log.debug('model =>', model);
      $log.debug('req.query =>', request.query);
   }

   @Post("/")
   post(@BodyParams() model: MyMongooseModel, @Req() request) {
      $log.debug('model =>', model);
      $log.debug('req.body =>', request.body);
   }
}

If there is an error in the model and in the request, the problem is related to body-params, qs or from the data itself (date format, json, etc...)

If there is an error only on model, tell me. The problem come from Ts.ED converters.

If you haven't problem, that means, the problem is after XD.

• Add log on different step where you touch the data and especially where you have transformation on the dates. If you have a problem on this step, it's your code ;)
• Add log just before insertion in database with mongoose and after insertion. If you have a problem on this step, it's a problem with mongoose/mongodb.

I think with that, you'll find your problem ;)
See you,
Romain

[dsasidhar]

Hey @Romakita ,
Thanks for the quick response, the reason I think the problem might be related to tsed is that, if you observe. In my Model, I have this line:

@Default(Date.now())
  @Property()
  createdOn: Date;

I do not set createdOn anywhere. But this is the line that sets createdOn in the database. If on one machine it is setting as date and another as double. Isn't the issue on tsed?

[Romakita]

Hum ok, the @Default(Date.now) is used by mongoose. I think the parameters is wrong.
In the official documentation we have that:

var schema = new Schema({

  createdOn: {
    type: Date,
    // `Date.now()` returns the current unix timestamp as a number
    default: Date.now
  }
});

So the equivalent with decorator should be:

@Default(Date.now)
@Property()
createdOn: Date;

Isn't a issue from Ts.ED but maybe it'll fix your problem ;)
Romain

[dsasidhar]

@Romakita I will try with that change, but it still doesn't explain why it was working for me on few machines and doesn't work on others.

[Romakita]

I haven't explaination for that XD. Date in javascript is magical :)

[milewski]

i had similar issues few days ago, it was a bit random as it was running on a CI and sometimes it pass some other time dont... the following fixed this randomness for me:

@Schema({ type: Date, default: Date.now })
public createdAt: Date

the reason was that sometimes the date would be the right format the test was expecting some other time it would be a number

[Romakita]

HOooo ok. I see what is the problem now :D

[dsasidhar]

i had similar issues few days ago, it was a bit random as it was running on a CI and sometimes it pass some other time dont... the following fixed this randomness for me:

@Schema({ type: Date, default: Date.now })
public createdAt: Date

the reason was that sometimes the date would be the right format the test was expecting some other time it would be a number

@milewski your solution solved the problem for me. Given the solution, I think the problem should be about tsed, because the problem doesn't exist when we have @Schema decorator but the problem exists when we use @Property decorator with a typescript type. These are tsed specific components. Any thanks for the support, and quick responses. So far this repo has been a good decision for my project. Cheers.

[dsasidhar]

@Romakita oops, I didn't see your comment, I closed the issue because my problem was solved. Please feel free to open it back up.