Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Model define default value can not work #15

Open
tears330 opened this issue Apr 28, 2021 · 4 comments
Open

Model define default value can not work #15

tears330 opened this issue Apr 28, 2021 · 4 comments
Labels
feature New feature or request

Comments

@tears330
Copy link

const validationResult = revalidator.validate(

Here is my model schema:

{
      id: {
        type: 'string',
        uniqueItems: true,
        required: true,
      },
      name: {
        type: 'string',
        required: true,
        uniqueItems: true,
      },
      createdAt: {
        type: 'number',
        required: true,
        default: Date.now
      },
      updatedAt: {
        type: 'number',
        required: true,
        default: Date.now
      },
    }

neogma model use revalidator to check the value , but revalidator has this issue flatiron/revalidator#85 , the default field does't implement.

How about use class-validator & class-transformer to replace the schema implement ?

Good

  • save a lot template code ( define interface & default validate rules )
  • got more feature (type transform & default value)

Bad

  • will cause a break change
@themetalfleece
Copy link
Owner

In the beginning I was using class-validator, but it was complicating things a lot (i.e. I had to befine the class anyway, then pass it to ModelFactory). So I ended up using a simple object validator.

For starters, I'd be a good idea for me to fork revalidator, implement default, merge the typings into it so they're build-in, and use it for neogma.
In the future, I could reconsider using class-validator and class-transformer.

For your issue, you could add a Before Create Hook which sets the default value.

YourModel.beforeCreate = (instance) => {
    if (!instance.createdAt) {
        instance.createdAt = Date.now;
    }
    if (!instance.updatedAt) {
        instance.updatedAt= Date.now;
    }
};

Of course this is not quite the same as a default value, as it runs only before saving an instance (which should work in your case).

Also, in case you want to use an actual neo4j date, you could do the following:

import { neo4jDriver } from 'neogma';

type YourProperties = {
    createdAt: neo4jDriver.DateTime<any>;
}

// in schema validation:
{            
    createdAt: {
        type: 'any',
        required: true,
        conform: (v) => neo4jDriver.isDateTime(v),
    }
}

// to create the date
const nowDateTime = neo4jDriver.types.DateTime.fromStandardDate(
    new Date(),
);

I don't know if there's an easier way 😅 Although I could implement an automatic transformation of neo4j <-> js Dates on an Instance level.

@themetalfleece themetalfleece added the feature New feature or request label Apr 28, 2021
@tears330
Copy link
Author

tears330 commented May 6, 2021

Sorry for late reply 🙈. Use beforeCreate hook can resolve my current problem.

I just want to use the basic timestamp to mark the node. It's too complex when I try to use neo4j Date Object ( have to implement the adapter for two different data structure on application layer ) .

If u want to use class-validator and class-transformer , how about consider using the typeorm style like that ?

@Node()
@Relation(() => Order)
export class User {
    @Property()
    id: number;

    @Property()
    firstName: string;

    @Property()
    lastName: string;

    @Property()
    age: number;

    @CreateDateProperty()
    createdAt: Date;
}

And load the entity file like

createConnection({
    url: 'bolt://127.0.0.1:7687',
    username: 'neo4j',
    password: 'neo4j',
    entities: [
        __dirname + "/entity/*.js"
    ]
}).then(connection => {
    // here you can start to work with your entities
}).catch(error => console.log(error));

@themetalfleece
Copy link
Owner

Thanks for all that info! It'll come in handy when I consider replacing revalidator

@tejo-ak
Copy link

tejo-ak commented Jun 4, 2021

I like the use of decorators as it helps the schema definition clean. The current way is so verbose, but it works. So, I do support decorator, but without removing the current style for backward compatibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants