Access control location with two $wildchilds returns error about blaze_compiler HOT 4 CLOSED

Actually, I don't think it's the two $wildchilds that is causing the problem. After some further debugging, it looks like this is a result of the schema "definition" for model reuse are implemented poorly.

For example, if I have a location like the following:

access:
  - location: "/a/path/"

And I have the schema set up the following way:

schema:
  definitions:
    path:
      type: object
      #other_stuff_in_path_definition

  a:
    type: object
    properties:
      path: {$ref: "#/definitions/path"}

When I attempt to "blaze" the YAML. it provides the following warnings during transpiling:

WARNING: /a/path in access rule but not in a schema

So, it appears that the referencing of models in `schema/definitions" is not working properly.

from blaze_compiler.

Hi I am on paternity leave at the moment, so probably can't get to this for
4 weeks. The bug you are seeing is an interaction with a newer feature of
schema padding. If you go back a couple of version it might temporarily
solve the issue.
On 21 Oct 2015 10:31 a.m., "Max Mueller" [email protected] wrote:

Actually, I don't think it's the two $wildchilds that is causing the
problem. After some further debugging, it looks like this is a result of
the schema "definition" for model reuse are implemented poorly.

For example, if I have a location like the following:

access:

• location: "/a/path/"

And I have the schema set up the following way:

schema:
definitions:
path:
type: object
#other_stuff_in_path_definition

a:
type: object
properties:
path: {$ref: "#/definitions/path"}

When I attempt to "blaze" the YAML. it provides the following warnings
during transpiling:

WARNING: /a/path in access rule but not in a schema

So, it appears that the referencing of models in `schema/definitions" is
not working properly.

—
Reply to this email directly or view it on GitHub
#64 (comment)
.

from blaze_compiler.

@tomlarkworthy, thanks for the note. For now, I'm just copying and pasting rather than using the reference, which isn't the end of the world, but when it's fixed it'll definitely help me clean things up. Also, I'm a little wary with moving around versions considering it seems like some features are somewhat fragile, so I'm gonna stay on this version and hope for the best.

Also, paternity leave typically means that there is a new addition to the family... so congratulations!

from blaze_compiler.

Thanks, actually it was 2 new additions :)
I can't replicate this, your example has a mistake in it, "a" is not a property of the root object, after correcting that I don't seem to get the warning:-

  schema:
    definitions:
      path:
        type: object
    properties:
      a:
        type: object
        properties:
          path: {$ref: "#/definitions/path"}

  access:
    - location: "/a/path/"
      read: true

    - location: "/DOST_NOT_EXIST/"
      read: true

I get just one warning, "WARNING: DOST_NOT_EXIST in access rule but not in a schema"

from blaze_compiler.