Add support for minProperties and maxProperties

[jewzaam]

There's no way to indicate a choice between to sub-documents today. Simple almost real example:

"identification": {
    "type": "object",
    "ssoUser": {
        "type": "object",
        "login": {
            "type": "string",
            "constraints": {
                "required": true
            }
        }
    },
    "nonSsoUser": {
        "firstName":{
            "type": "string",
            "constraints": {
                "required": true
            }
        },
        "lastName":
            "type": "string",
            "constraints": {
                "required": true
            }
        },
        "emailAddress":
            "type": "string",
            "constraints": {
                "required": true
            }
        }
    }
}

I don't think there's a way to say you have to have either ssoUser or nonSsoUser.

The metadata json schema already supports minProperties and maxProperties. Code doesn't use it. To fix this, we could add a constraint on the "identification" object to set minProperties: 1

[luan-cestari]

I the end of the description, " to set minProperties: 1" would be " to set maxProperties: 1" right? Another alternative would use the 'oneOf' constraint to make just one of those fields be used at a time.

[jewzaam]

True, should in this case both min and max properties to 1. 'oneOf' would work as well, but leaves no possibility for limiting the max if it's more than 1 max. Maybe we want 3 of 4 fields filled in. Of those choice constructs that json schema gives, only oneOf seems to be very useful. The 'anyOf' isn't necessary for metadata and 'allOf' can be handled by making everything required.

[luan-cestari]

You right (about min and max, both) and the other scenarios. I thought we could mix the oneOf with other required fields (so some of them would have the constraint and other would be just simple usual fields)

Luan Cestari

"All the gold which is under or upon the earth is not enough to give in exchange for virtue." Plato "At his best, man is the noblest of all animals; separated from law and justice he is the worst." "A true friend is one soul in two bodies." Aristotle "The only limit to your impact is your imagination and commitment." Tony Robbins

On Fri, Jul 25, 2014 at 2:11 PM, Naveen Malik notifications@github.com wrote:

True, should in this case both min and max properties to 1. 'oneOf' would work as well, but leaves no possibility for limiting the max if it's more than 1 max. Maybe we want 3 of 4 fields filled in. Of those choice constructs that json schema gives, only oneOf seems to be very useful. The 'anyOf' isn't necessary for metadata and 'allOf' can be handled by making everything required.

— Reply to this email directly or view it on GitHub https://github.com/lightblue-platform/lightblue/issues/82#issuecomment-50177719 .

[vritant]

@luan-cestari @jewzaam min and max is enough to indicate choice, but could there be use cases to indicate a specific order in which fields should occur ? if yes, then the solution to that problem can go hand in hand with the choice problem

[bserdar]

Field ordering is not enforced.

On Mon, Jan 26, 2015 at 11:24 AM, Vritant Jain notifications@github.com wrote:

@luan-cestari https://github.com/luan-cestari @jewzaam https://github.com/jewzaam min and max is enough to indicate choice, but could there be use cases to indicate a specific order in which fields should occur ? if yes, then the solution to that problem can go hand in hand with the choice problem

— Reply to this email directly or view it on GitHub https://github.com/lightblue-platform/lightblue-core/issues/82#issuecomment-71510096 .

[vritant]

@bserdar it is not enforced, but is it an option ? if not, should it be?

[bserdar]

Based on the way we process documents, it is very difficult to enforce field ordering. These are named fields, and we access them by name. If you have data that you want ordered in some way, put them in an array. Array element ordering is significant.

On Mon, Jan 26, 2015 at 12:28 PM, Vritant Jain notifications@github.com wrote:

@bserdar https://github.com/bserdar it is not enforced, but is it an option ? if not, should it be?

— Reply to this email directly or view it on GitHub https://github.com/lightblue-platform/lightblue-core/issues/82#issuecomment-71521418 .

[vritant]

makes sense. thanks.

[jewzaam]

It's json.. it's not enforceable.