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

Using "Any" generates incorrect rules #111

Closed
mm-gmbd opened this issue Jan 11, 2016 · 5 comments
Closed

Using "Any" generates incorrect rules #111

mm-gmbd opened this issue Jan 11, 2016 · 5 comments
Labels

Comments

@mm-gmbd
Copy link

mm-gmbd commented Jan 11, 2016

Consider the following setup:

type MyType {
  num: Number,
  str: String,
  any: Any
}

path / {
  read()  = true;
  write() = true;
}

path /path is MyType {
  read() = true();
  write() = true();
}

The third property of MyType is defined as type Any, so I would expect that, at path in the rules, it would ensure that any was included in a newData.hasChildren([]) statement, and then the specific .validate rule would check to ensure that it wasn't null. However, the following rules are generated:

{
  "rules": {
    "path": {
      ".validate": "newData.hasChildren(['num', 'str', 'any'])",
      "num": {
        ".validate": "newData.isNumber()"
      },
      "str": {
        ".validate": "newData.isString()"
      },
      "$other": {
        ".validate": "false"
      },
      ".read": "true()",
      ".write": "true()"
    }
  }
}

Notice the complete lack of a .validate rule for any, even though the parent .validate includes it in .hasChildren(). Because this is left out, the $other wildcard .validate: false rule breaks the rule generation!

@mckoss
Copy link
Contributor

mckoss commented Jan 11, 2016

Yes! Same cause as issue #97.

@mckoss mckoss added the bug label Jan 11, 2016
@mm-gmbd
Copy link
Author

mm-gmbd commented Apr 21, 2016

Hey @mckoss - any update on this one? I just revisited some rules, used Any as a type, and fell into the same pitfall. Looking at the docs indicated that I wasn't doing anything wrong, but I had to come here to remember the issue - maybe the docs could be updated in the meantime (i.e. next to "Any" there could be a warning that says not to use it, or it could be removed entirely for now)?

@RomansBermans
Copy link

Hey @mckoss I am trying to rewrite the Firebase Queue rules from JSON to Bolt and below is the case when type Any doesn't work:

...
type TaskErrorDetails {
  error: NonEmptyString | Null,
  error_stack: NonEmptyString | Null,
  previous_state: NonEmptyString | Null,
  original_task: Any | Null,
  attempts: GreaterThanZeroNumber | Null
}
...

Will generate:

...
"_error_details": {
  ".validate": "newData.hasChildren() || newData.val() == null",
  "error": {
    ".validate": "newData.isString() && newData.val().length > 0 || newData.val() == null"
  },
  "error_stack": {
    ".validate": "newData.isString() && newData.val().length > 0 || newData.val() == null"
  },
  "previous_state": {
    ".validate": "newData.isString() && newData.val().length > 0 || newData.val() == null"
  },
  "attempts": {
    ".validate": "newData.isNumber() && newData.val() > 0 || newData.val() == null"
  },
  "$other": {
    ".validate": "false"
  }
}
...

As you can see original_task has been removed from the generated rules.

If on the other hand I try to generate them from the following:

...
type TaskErrorDetails {
  error: NonEmptyString | Null,
  error_stack: NonEmptyString | Null,
  previous_state: NonEmptyString | Null,
  original_task: Any,
  attempts: GreaterThanZeroNumber | Null
}
...

I get:

...
"_error_details": {
  ".validate": "newData.hasChildren() && newData.hasChildren(['original_task']) || newData.val() == null",
  "error": {
    ".validate": "newData.isString() && newData.val().length > 0 || newData.val() == null"
  },
  "error_stack": {
    ".validate": "newData.isString() && newData.val().length > 0 || newData.val() == null"
  },
  "previous_state": {
    ".validate": "newData.isString() && newData.val().length > 0 || newData.val() == null"
  },
  "attempts": {
    ".validate": "newData.isNumber() && newData.val() > 0 || newData.val() == null"
  },
  "$other": {
    ".validate": "false"
  }
}
...

Again the original_task has been removed from the generated rules, but .validate references it.

@pandaiolo
Copy link

Hi

Also bumped into this issue. I use this workaround:

// Use this instead of type `Any`
type Anything {
    validate() {
        this.isString() || this.isNumber() || this.isBoolean() || this.hasChildren()
    }
}

mckoss added a commit that referenced this issue Aug 3, 2016
Fixes issue #111 - don't prematurely optimize .validate: true rules in presence of $other sibling.
@mckoss
Copy link
Contributor

mckoss commented Aug 4, 2016

Fixed by PR #166

@mckoss mckoss closed this as completed Aug 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants