Validation and Schema

[Timu57]

As pointed out by @daussho in #177 it is a good idea to implement a Schema feature to make validation with features like "unique" possible.

That schema could include many conditions to validate new documents before inserting them:

• required
• unique
• int
• float
• min
• minLength
• maxLength
• array
• string
• email
• numeric
• AND MUCH MORE...

Interesting libraries are:

https://github.com/laravel/framework/tree/8.x/src/Illuminate/Validation
Documentation:
https://laravel.com/docs/8.x/validation

AND:

https://github.com/rakit/validation

Storing the keys is no longer required

@prashant-saxena had a great idea in #211 . Instead of saving the data as a key-value pair in a json-file we could just save the value. Then the data could look like this:

["Google Pixel XL","Google announced a new Pixel!","06,05,2021",5.2365, 2]

[oCyex]

@Timu57
I'm considering trying SleekDB as well as https://github.com/nette/schema
It could be a good team, right?

[Timu57]

Hi @oCyex

Sure, SleekDB does nothing schema related, so if you want to use another library to enforce a schema, you are free to do so ☺️

SleekDB doesn't restrict you in any way 😁

[oCyex]

@Timu57 Yeah!

It's just I thought it was the perfect libraries to get inspired for what you wanted to do ;)

[bespired]

Hi. I’m pretty new to this.
If this is “discussion” then I’d like to add I really dislike DB (nerds) way of thinking about “types”.
Laravel way of validation is very bad as well.
It’s all very nice and dandy to validate if a color is a string or an int but it’s useless.
And it’s all cool and great to store an age in an int or in a bigInt but next year I’ll be a year older. My birthday will stay the same forever, as the color of my eyes, but my hair will turn grey, and my address has a country, city, zipcode, street, house number in some countries, and others don’t. But I can move. Some house numbers have letters. Some addresses are a description on how to get there. With 2 large numbers any point on earth can be defined.

Far to often the DB validation of values is based on the way it should store it, and not about what the value represents in real life.
How fluid is the value? How is it changeable towards time? How should the front end render it?
If you’re going to store everything as a string I don’t see any reason to validate the values towards 1980’s types (int/long/double/string).

You will still be able to store 42 as a string in the variable “color”… and you will still have no idea how to render it, or if will be 42 forever or just today. Or is it even a color or an index to a color?

Just my 2 cents.
I’ve been writing about 7 years now on software that collects data from websites and haven’t found any software that understands values.
And all solutions keep asking the developer to help the software on how it should store the data, it’s 2021 for heaven sake.