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

Merges the changes from the release/3.0 branch to release/4.0 branch #345

Closed
wants to merge 10 commits into from

Conversation

nikcio
Copy link
Contributor

@nikcio nikcio commented Jul 27, 2023

This merges the changes in the release/3.0 branch to the release/4.0 branch. This primarily contains #320.

@nzdev Is there any way we can use faceting and the feature in #320 at the same time? I couldn't see an obvious way to accomplice this.

And @nzdev What would be a good XML comment for ShardIndex in the src/Examine.Lucene/Search/LuceneSearchResult.cs file?

@nikcio nikcio marked this pull request as ready for review July 27, 2023 05:58
@nzdev
Copy link
Contributor

nzdev commented Jul 27, 2023

#321 is facet deep paging

@nikcio
Copy link
Contributor Author

nikcio commented Jul 27, 2023

@nzdev Oh yes right. Could you then take a look at the LuceneSearchExecutor changes in this PR and see if it is merged correctly? - when testing all the tests succeed😁

@nikcio nikcio mentioned this pull request Jul 28, 2023
5 tasks
@nzdev
Copy link
Contributor

nzdev commented Jul 29, 2023

Here's what I'm thinking.
Have the next release of Examine be 4.0, but avoid breaking API changes for 3.x. This means Umbraco 10 and 12 can choose to relax the allowed Examine version to be v3 or v4.

Steps:

  1. Merge PR Record v3 shipped API using Microsoft.CodeAnalysis.PublicApiAnalyzers #346 which tracks the shipped API for V3.
  2. Merge PR Fix V4 compatibility with V3 API #347 which merges V3 into V4 and fixes any API compatibility issues.
  3. Rebase Merges the changes from the release/3.0 branch to release/4.0 branch #345 to fix any nullability / xml docs issues.
  4. Add the new api's as unshipped to the txt files and release a beta
  5. Allow time for feedback, resolve feedback, add new api to the shipped.txt files. (regen the files to include tracking API nullability annotations. This is due to v3 not making nullability claims)
  6. Release 4.0

@Shazwazza
Copy link
Owner

Looks like conflicts need to be resolved

Comment on lines +54 to +66
//protected override void Dispose(bool disposing)
//{
//if (!_disposedValue)
//{
// if (disposing)
// {
// _searcherManager.Dispose();
// }

// _disposedValue = true;
//}
//base.Dispose(disposing);
//}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will replace the new virtual when possible to align with the dispose pattern.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this would break any classes overriding public virtual void Dispose(). We should revert to keep compatibility and mark as obsolete in V5.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is commented out I can't see it being problematic before uncommented?

Comment on lines 101 to 120
public virtual FacetsConfig GetDefaultFacetConfig() => new FacetsConfig();

/// <summary>
/// Disposes of the searcher
/// </summary>
/// <param name="disposing"></param>
protected virtual void Dispose(bool disposing)
{
return new FacetsConfig();
if (!_disposedValue)
{
_disposedValue = true;
}
}

/// <inheritdoc/>
public virtual void Dispose()
/// <inheritdoc />
public void Dispose()
{

// Do not change this code. Put cleanup code in 'Dispose(bool disposing)' method
Dispose(disposing: true);
GC.SuppressFinalize(this);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Align with the dispose pattern

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this would break any classes overriding public virtual void Dispose(). We should revert to keep compatibility and mark as obsolete in V5.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nzdev I've readded the virtual modifier and added an Obsolete attribute describing that you should override the Dispose(bool) instead.

@nikcio
Copy link
Contributor Author

nikcio commented Aug 16, 2023

@Shazwazza This is now updated. I've fixed all warnings that isn't part of the RSxxx warnings and had a simple fix. Above I've added some comments to the most important points of interest.

@nzdev
Copy link
Contributor

nzdev commented Aug 16, 2023

RS0036 should still be active. The unshipped API .txts files should get deleted and regenerated now that nullable / API should be ready. Will review rest later

@nikcio
Copy link
Contributor Author

nikcio commented Aug 16, 2023

@nzdev super then we can remove the nowarn

@nikcio
Copy link
Contributor Author

nikcio commented Aug 23, 2023

RS0036 should still be active. The unshipped API .txts files should get deleted and regenerated now that nullable / API should be ready. Will review rest later

@nzdev I tried generating the files but couldn't seem to get all the warnings to go away may be I'm doing something incorrectly.

But I think the Directory.Build.props should have this configuration at the bottom:

  <!-- Disable the nullable warnings when compiling for .NET Standard 2.0 -->
  <PropertyGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">
    <NoWarn>$(NoWarn);nullable;RS0037</NoWarn>
  </PropertyGroup>

  <ItemGroup Condition="'$(MSBuildProjectName)' != 'Examine.Web.Demo' AND '$(MSBuildProjectName)' != 'Examine.Test'">
    <AdditionalFiles Include="PublicAPI/$(TargetFramework)/PublicAPI.Shipped.txt" />
    <AdditionalFiles Include="PublicAPI/$(TargetFramework)/PublicAPI.Unshipped.txt" />
  </ItemGroup>

I think we need to ignore RS0037 on netstandard2.0 because we don't fully support nullable on this target and for the same reason I think we need to have a PublicAPI file for each of the target frameworks. What do you think and could you help me with generating the PublicAPI files correctly?

@nzdev
Copy link
Contributor

nzdev commented Aug 25, 2023

#349 addresses the public API files and fixes / suppresses most of the warnings.

@nikcio
Copy link
Contributor Author

nikcio commented Aug 26, 2023

#349 should include everything from this one so i'll close this one

@nikcio nikcio closed this Aug 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants