mORMot Open Source

mrbar2000

Member

From: Brazil

Registered: 2016-10-26

Posts: 56

Validation, Nullables, FKs

I start my study and develop with mormot, congratulations, excelent framework.

Some doubts.

1) I see on documentation that I can use TNullableXXX to treat nullables.
This is working on mormot2?
How ORM can create database field as "not null"? CreateMissingTables are creating all fields as "accept null"

2) Where I find the validators class to make things as:
    - field is filled or is null (field integer or string).
    - Length validator
    - max and min values
    - number interval
    - etc... (i just see to ipvalidator email and some others)

3) Serious that framwork do not generate FK Keys?
    This is a great problem when database is filled by others applications, or if the programmer need make changes on database directly.
    how u grant the integrity in yours applications guys?

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,206

Website

Re: Validation, Nullables, FKs

1) Yes, this has not been changed and should work with mORMot 2.
And yes, the ORM create always all columns as NULLABLE, even if the types are not.

2) You have a set of TSynFilter and TSynValidate sub-classes available at ORM level. See mormot.core.search.pas.
They are not translated to the DB, just available at ORM level before making the Add/Update.
This is because some DB does not support such validation.

3) For the same reasons, no FK are created by the ORM.
Since some database backends do not support FK, we make it at the ORM level.
For instance, our in-memory engine does not support FK. Nor does MongoDB. And we support both.

What is supported for instance is unique fields, since all engines (even our in-memory engine) support it.

In short, you are right, in mORMot the data integrity is not meant to be in the DB but at business logic / ORM level.
The mORMot pattern is to put the logic within the business code, not within the DB. It follows patterns like the "Persistence pattern" or the "Aggregate pattern".
Even more, in the context of MicroServices which mORMot favors and easily implement, it is an anti-pattern to let other projects make direct changes to the DB, since this data should be owned by the service itself.
So if you want a full relational model in your DB, you should add the constraints yourself by a few SQL calls.

mrbar2000

Member

From: Brazil

Registered: 2016-10-26

Posts: 56

Re: Validation, Nullables, FKs

2) You have a set of TSynFilter and TSynValidate sub-classes available at ORM level.

Ok then, if by sample, I want validate a integer field at ORM Level, to just receive values > 5, what validate TSynValidate sub-classes i should be to use? TSynValidatePattern? I hate regular expressions. How u would do? should I be make others subclasses?

ti-pattern to let other projects make direct changes to the DB (******* I AGREE *******)

All right. Still talking about foreign key, constraints, and not null fields. Is there any way to intercept the creation of the table and fields in order to add these options to the database according to the reading via RTTI of the TOrm classes? I know that some types database does not have these options, but most databases have.

Maybe we can embedded some class on ORM that implement some interface where we could put things like foreign key, constraints, not null fields, descriptions etc...

I'm only saying this Arnold because many developers are so rooted in their old relational paradigms that they would find it very odd that the ORM framework doesn't provide this natively. Then we could offer the possibility for these people to see MORMOT as a tool they can trust. not that it makes a difference to you or me. do you understand?

What you think?

Last edited by mrbar2000 (2023-03-03 01:45:22)

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,206

Website

Re: Validation, Nullables, FKs

You have TSynValidateText for length pattern.

And usually, you could create the table by tuned SQL before calling CreateMissingTables.
It is the most versatile way.
If the table already exists, the ORM won't create its own schema.

I have added an entry in the framework documentation FAQ about this.