-
Notifications
You must be signed in to change notification settings - Fork 218
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
[Python] Initial fixes using simple oneOf
s with discriminator
#4435
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
3a15f0a
to
5112a5a
Compare
{ | ||
// Prevent duplicates |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those changes are fixing #4178
Please note that two properties with colliding serialization names are going to collide anyway causing just an even more subtle runtime error.
I believe this is an improvement that doesn't impact code that was already correct, but it would be great to test the changes on the Graph API to confirm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To test in other projects I used a pre-release pipeline:
https://github.com/andreaTP/kiota-prerelease/releases/tag/v0.0.0-pre%2BandreaTP.initial-fixes-simple-oneOf-py.b46369a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andreaTP The PR looks good from my end. I just need to run some tests on the graph api metadata and I'll confirm if everything is good here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙏 thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at microsoftgraph/msgraph-sdk-dotnet@dev...kiota/v1.0/pipelinebuild/142930
It looks like there's something we need to rethink here. It looks like kiota expects the property to be added to the codeDom either way if it exists up the hierarchy.
The relevant writer/refiner of the language will then use the ExistsInBaseType
property to determine whether the property should be redifined in the child type based on the language semantics. It also allows the property to hold multiple values based on the context(if we are in the base or child class) in scenarios for default values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The groupby here is fine, it'd prevent somebody from adding twice the same property from the same schema. Unlikely because of the conventions of JSON schema, but fine.
What's really problematic here is this if block, it effectively breaks behaviour with overridden defaults in derived types. Can you provide more context on why do you think it's necessary in an oneOf scenario @andreaTP please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without the check, a discriminator property is added multiple times (as reported in other issues) and it breaks serialization/deserialization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and that discriminator property being added multiple times only happens whenever we have a union type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know, it happens for sure when we have a union type, if this is the only case I cannot tell.
IIRC the discriminator gets added +2 times anytime the schema declaring it appears in the OpenAPI definition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can verify the behavior by using the reproducer: https://github.com/microsoft/kiota/pull/4435/files#diff-2862479147a7917233ba0a4bc0e346b2e297c170b54b431a1c3f511765e2ca53
@baywet @andrueastman to your attention as I hope we can get this one(or the resolution of the linked issues in another form) at your earliest 🙏 |
The "build" failure is correct as I haven't finished fixing the unit tests according to the new implementation 😅 doing it now. |
Moving back to draft as I need a little guidance on the failing tests, I think that I'm missing an invariant, but struggling to get it right for all the use cases. |
if anyone of the maintainers is available to point me in the right direction or helping out it would be much appreciated 🙏 |
|
Apologize I forgot to follow up, @baywet I think that I do not fully understand all the use cases, it will be great if you can look into this 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for starting this.
@andreaTP Do you have any specific question regarding the guidance you're looking for here? Through reviewing the issue and the PR I couldn't see any outstanding questions?
@@ -35,6 +35,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 | |||
- Changed Csharp code generation to put braces on new lines (where it makes sense). [#4347](https://github.com/microsoft/kiota/issues/4347) | |||
- Fixed a bug where some no-content status codes would be considered structured (301, 302, 303, 307) when described. [#4190](https://github.com/microsoft/kiota/issues/4190) | |||
- TypeScript is now a preview language! | |||
- Fixed a bug where the code generated for Python in presence of discriminator values was not compiling/working. [#4433](https://github.com/microsoft/kiota/issues/4433) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this needs to be moved to the unreleased section
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I'll do it
var className = parentClass.Name; | ||
if (parentClass.Parent is CodeClass pc && | ||
!string.IsNullOrEmpty(pc.Name) && | ||
pc.InnerClasses.Any(x => x == parentClass)) | ||
{ | ||
className = $"{pc.Name}.{parentClass.Name}"; | ||
} | ||
writer.WriteLine($"{ResultVarName} = {className}()"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm struggling to understand what's happening here. By definition the wrapper class cannot/shouldn't be one of the member types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤷♂️ I just changed the code that was not compiling, not sure if there is a more principled fix for the issue.
Co-authored-by: Vincent Biret <[email protected]>
@baywet thanks for getting back on this! If you can have a look at the failing unit tests you can probably give me some answers ... |
@andreaTP I fixed all the failing unit tests by simply removing the if block I was referring to here but didn't push my changes as I wanted to get more context on the matter first. |
@baywet thanks a lot for checking this one! Alternatively, I can get back to this early next week. |
For the records, this is still an issue as far as I can tell, but it dropped on my priority list and it would be great if someone would take over. |
Fixes #4433