Make code output stable across multiple runs about php-json-schema-model-generator

[dktapps]

Is there a specific reason why you commit the generated code?

I'm currently experimenting with this library and it seemed like the simplest way to do it right now, because otherwise deploy involves two extra steps (install dev deps, generate code, then install non-dev deps). I haven't settled on how I'm going to use it right now.

The ArrayItemValidator on the other hand currently needs the suffix. You're right, each property is evaluated in a single function so conflicts won't occur. But if a property contains a nested array the validation for the property will contain nested array validators in a single function which will collide and overwrite each others invalid items collection (if the variable names are identical, eg. both use $invalidItems).

I did some experimentation and found that a hash of this seems to be sufficient for nested arrays.

[dktapps]

For the ArrayItemValidator case it seems like md5(propertyName) is sufficient. I checked nested arrays and their property names are item of {actualPropertyName}, so this seems fine.

[wol-soft]

I've had a quick view: for the AbstractPropertyProvider I think the uniqid is not necessary, as you already stated in the issue description.

The ArrayItemValidator on the other hand currently needs the suffix. You're right, each property is evaluated in a single function so conflicts won't occur. But if a property contains a nested array the validation for the property will contain nested array validators in a single function which will collide and overwrite each others invalid items collection (if the variable names are identical, eg. both use $invalidItems).

Consequently some kind of 'nested level counter' or something similar would be required to generate a reproducable suffix for the variable names. I'll have a look into it the next days.

For all my usages of the library, I don't commit the generated code (as it's just a duplication in my opinion. All information is already committed in the JSON-files used to generate the classes). I run my generate-script as a build step of the applications (like composer install to not commit the vendor directory). Is there a specific reason why you commit the generated code?

[wol-soft]

I did some experimentation and found that a hash of this seems to be sufficient for nested arrays.

Yes, you are absolutely right. Clean and simple solution. I've added it in 1b7a21a to the master as well as a patch for the AbstractPropertyProvider. You may test it with the latest master version.

Thanks for the hint 😃

[dktapps]

Thanks. Only thing that remains (AFAIK) is the ClassNameGenerator, but I solved that with my code using a custom impl that just md5's the contents of the json schema. There's probably a better way to do it though (is there a way to get the full property path in there?).

[dktapps]

Is there a specific reason why you commit the generated code?

I just want to mention something in addition to what I said before, which is that as well as making initial install as root project more complicated, codegen on install is not an option if the package may be used as a library, since dev deps won't be available. In that case, the only choices are to either commit the code or to depend on the codegen tool as a non-dev dep, neither of which are ideal. I think committing the code is the lesser evil in this case.

[wol-soft]

Yes, using this library in a library context currently has no proper solution. Maybe it's possible to wrap the generate script into a Composer plugin. I've not yet tested this idea.