odata.net
odata.net copied to clipboard
OData
Fix "OriginalNameAttribute not being captured when DataServiceQuery<T> is casted to DataServiceQuery<InterfaceT>"
Issues
This pull request fixes #2856.
Description
Capture member from original class, so attributes are not lost in case the query generic parameter is casted to an interface.
Checklist (Uncheck if it is not completed)
- [x] Test cases added
- [x] Build and test with one-click build and test script passed
This PR has 3 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!
Quantification details
Label : Extra Small
Size : +2 -1
Percentile : 1.2%
Total files changed: 1
Change summary by file extension:
.cs : +2 -1
Change counts above are quantified counts, based on the PullRequestQuantifier customizations.
Why proper sizing of changes matters
Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean:
- Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer iterations.
- Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
- Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.
What can I do to optimize my changes
- Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the
Excludedsection from yourprquantifier.yamlcontext profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your
prquantifier.yamlcontext profile. - Only use the labels that matter to you, see context specification to customize your
prquantifier.yamlcontext profile.
- Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
- Your PR could be split in smaller, self-contained PRs instead
- Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).
- For PRs that fall outside of the desired spectrum, review the details and check if:
How to interpret the change counts in git diff output
- One line was added:
+1 -0 - One line was deleted:
+0 -1 - One line was modified:
+1 -1(git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.
Was this comment helpful? :thumbsup: :ok_hand: :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.
![pull-request-quantifier-deprecated[bot] avatar](https://avatars.githubusercontent.com/in/93966?v=4 "Published by a pub.dev verified publisher"){kind=small}
This PR has 155 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!
Quantification details
Label : Medium
Size : +153 -2
Percentile : 51%
Total files changed: 3
Change summary by file extension:
.cs : +153 -2
Change counts above are quantified counts, based on the PullRequestQuantifier customizations.
Why proper sizing of changes matters
Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean:
- Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer iterations.
- Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
- Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.
What can I do to optimize my changes
- Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the
Excludedsection from yourprquantifier.yamlcontext profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your
prquantifier.yamlcontext profile. - Only use the labels that matter to you, see context specification to customize your
prquantifier.yamlcontext profile.
- Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
- Your PR could be split in smaller, self-contained PRs instead
- Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).
- For PRs that fall outside of the desired spectrum, review the details and check if:
How to interpret the change counts in git diff output
- One line was added:
+1 -0 - One line was deleted:
+0 -1 - One line was modified:
+1 -1(git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.
Was this comment helpful? :thumbsup: :ok_hand: :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.
This PR has 155 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!
Quantification details
Label : Medium
Size : +153 -2
Percentile : 51%
Total files changed: 3
Change summary by file extension:
.cs : +153 -2
Change counts above are quantified counts, based on the PullRequestQuantifier customizations.
Why proper sizing of changes matters
Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean:
- Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer iterations.
- Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
- Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.
What can I do to optimize my changes
- Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the
Excludedsection from yourprquantifier.yamlcontext profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your
prquantifier.yamlcontext profile. - Only use the labels that matter to you, see context specification to customize your
prquantifier.yamlcontext profile.
- Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
- Your PR could be split in smaller, self-contained PRs instead
- Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).
- For PRs that fall outside of the desired spectrum, review the details and check if:
How to interpret the change counts in git diff output
- One line was added:
+1 -0 - One line was deleted:
+0 -1 - One line was modified:
+1 -1(git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.
Was this comment helpful? :thumbsup: :ok_hand: :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.
This PR has 155 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!
Quantification details
Label : Medium
Size : +153 -2
Percentile : 51%
Total files changed: 3
Change summary by file extension:
.cs : +153 -2
Change counts above are quantified counts, based on the PullRequestQuantifier customizations.
Why proper sizing of changes matters
Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean:
- Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer iterations.
- Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
- Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.
What can I do to optimize my changes
- Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the
Excludedsection from yourprquantifier.yamlcontext profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your
prquantifier.yamlcontext profile. - Only use the labels that matter to you, see context specification to customize your
prquantifier.yamlcontext profile.
- Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
- Your PR could be split in smaller, self-contained PRs instead
- Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).
- For PRs that fall outside of the desired spectrum, review the details and check if:
How to interpret the change counts in git diff output
- One line was added:
+1 -0 - One line was deleted:
+0 -1 - One line was modified:
+1 -1(git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.
Was this comment helpful? :thumbsup: :ok_hand: :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.
This PR has 156 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!
Quantification details
Label : Medium
Size : +154 -2
Percentile : 51.2%
Total files changed: 3
Change summary by file extension:
.cs : +154 -2
Change counts above are quantified counts, based on the PullRequestQuantifier customizations.
Why proper sizing of changes matters
Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean:
- Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer iterations.
- Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
- Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.
What can I do to optimize my changes
- Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the
Excludedsection from yourprquantifier.yamlcontext profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your
prquantifier.yamlcontext profile. - Only use the labels that matter to you, see context specification to customize your
prquantifier.yamlcontext profile.
- Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
- Your PR could be split in smaller, self-contained PRs instead
- Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).
- For PRs that fall outside of the desired spectrum, review the details and check if:
How to interpret the change counts in git diff output
- One line was added:
+1 -0 - One line was deleted:
+0 -1 - One line was modified:
+1 -1(git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.
Was this comment helpful? :thumbsup: :ok_hand: :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.
I fixed the code in order to pass those failed tests.
Also, I found a third related issue:
If you try to run this code It will throw Exception:
[Key("CustomerID")]
public class BaseCustomer
{
[OriginalName("CustomerID")]
public string Id { get; set; }
}
public class OneLevelCustomer2 : BaseCustomer
{
public string City { get; set; }
}
// Test:
IQueryable<OneLevelCustomer2> q = ctx.OneLevelCustomers2; // ctx.OneLevelCustomers2 is a DataServiceQuery<OneLevelCustomer2>
var r = q.First();
The current value 'Microsoft.OData.Client.Tests.ALinq.BaseCustomer' type is not compatible with the expected 'Microsoft.OData.Client.Tests.ALinq.OneLevelCustomer2' type.
at Microsoft.OData.Client.Materialization.EntityTrackingAdapter.TryResolveFromContext(MaterializerEntry entry, Type expectedEntryType) in /workspaces/testnet/odata.net/src/Microsoft.OData.Client/Materialization/EntityTrackingAdapter.cs:line 187
at Microsoft.OData.Client.Materialization.EntityTrackingAdapter.TryResolveAsExistingEntry(MaterializerEntry entry, Type expectedEntryType) in /workspaces/testnet/odata.net/src/Microsoft.OData.Client/Materialization/EntityTrackingAdapter.cs:line 137
at Microsoft.OData.Client.Materialization.EntityTrackingAdapter.TryResolveExistingEntity(MaterializerEntry entry, Type expectedEntryType) in /workspaces/testnet/odata.net/src/Microsoft.OData.Client/Materialization/EntityTrackingAdapter.cs:line 107
at Microsoft.OData.Client.Materialization.EntryValueMaterializationPolicy.Materialize(MaterializerEntry entry, Type expectedEntryType, Boolean includeLinks) in /workspaces/testnet/odata.net/src/Microsoft.OData.Client/Materialization/EntryValueMaterializationPolicy.cs:line 197
at Microsoft.OData.Client.Materialization.ODataEntityMaterializer.DirectMaterializePlan(ODataEntityMaterializer materializer, MaterializerEntry entry, Type expectedEntryType) in /workspaces/testnet/odata.net/src/Microsoft.OData.Client/Materialization/ODataEntityMaterializer.cs:line 573
at Microsoft.OData.Client.Materialization.ODataEntityMaterializerInvoker.DirectMaterializePlan(Object materializer, Object entry, Type expectedEntryType) in /workspaces/testnet/odata.net/src/Microsoft.OData.Client/Materialization/ODataEntityMaterializerInvoker.cs:line 175
at Microsoft.OData.Client.ProjectionPlan.Run(ODataEntityMaterializer materializer, ODataResource entry, Type expectedType) in /workspaces/testnet/odata.net/src/Microsoft.OData.Client/ProjectionPlan.cs:line 78
at Microsoft.OData.Client.Materialization.ODataEntityMaterializer.ReadImplementation() in /workspaces/testnet/odata.net/src/Microsoft.OData.Client/Materialization/ODataEntityMaterializer.cs:line 927
at Microsoft.OData.Client.Materialization.ODataMaterializer.Read() in /workspaces/testnet/odata.net/src/Microsoft.OData.Client/Materialization/ODataMaterializer.cs:line 336
at Microsoft.OData.Client.MaterializeAtom.MoveNextInternal() in /workspaces/testnet/odata.net/src/Microsoft.OData.Client/MaterializeFromAtom.cs:line 349
at Microsoft.OData.Client.MaterializeAtom.MoveNext() in /workspaces/testnet/odata.net/src/Microsoft.OData.Client/MaterializeFromAtom.cs:line 281
at System.Linq.Enumerable.CastIterator[TResult](IEnumerable source)+MoveNext()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at Microsoft.OData.Client.Tests.ALinq.PreserveTypesAndAttributesTests.OneLevelCase2() in /workspaces/testnet/odata.net/test/FunctionalTests/Microsoft.OData.Client.Tests/ALinq/PreserveTypesAndAttributesTests.cs:line 53
at Program.<Main>$(String[] args) in /workspaces/testnet/tests/Program.cs:line 102
This error exists before my PR. I guess it could be easily fixeable too.
This PR has 156 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!
Quantification details
Label : Medium
Size : +154 -2
Percentile : 51.2%
Total files changed: 3
Change summary by file extension:
.cs : +154 -2
Change counts above are quantified counts, based on the PullRequestQuantifier customizations.
Why proper sizing of changes matters
Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean:
- Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer iterations.
- Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
- Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.
What can I do to optimize my changes
- Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the
Excludedsection from yourprquantifier.yamlcontext profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your
prquantifier.yamlcontext profile. - Only use the labels that matter to you, see context specification to customize your
prquantifier.yamlcontext profile.
- Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
- Your PR could be split in smaller, self-contained PRs instead
- Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).
- For PRs that fall outside of the desired spectrum, review the details and check if:
How to interpret the change counts in git diff output
- One line was added:
+1 -0 - One line was deleted:
+0 -1 - One line was modified:
+1 -1(git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.
Was this comment helpful? :thumbsup: :ok_hand: :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.
Could I please receive any feedback from the review process? @habbes @wachugamaina @gathogojr @xuzhg Thanks in advance