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

(GH-431) Add Count to List Command API #430

Merged
merged 3 commits into from
Oct 7, 2015

Conversation

RichiCoder1
Copy link
Contributor

Adds the ability to efficiently retrieve a "count" for a given list command. Usefully for when you want to total number of given packages for a command that meets certain search criteria, but you're also using paging and need a reliable "total". Mostly only relevant to NuGet at this point.

Closes #431

.Where(p => configuration.Prerelease || p.IsReleaseVersion())
.distinct_last(PackageEqualityComparer.Id, PackageComparer.Version)
.Count();
}
Copy link
Member

Choose a reason for hiding this comment

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

This method could literally call return GetPackages(config, nugetLogger).Count();. Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If they specified paging, then Count() would be inaccurate. The though process here is you could use the same config for both List and Count, and count would return the correct result.

Copy link
Member

Choose a reason for hiding this comment

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

You could change the config momentarily. I'm more of a fan of that than I am duplicating code.

@ferventcoder
Copy link
Member

This needs a ticket filed on it.

@ferventcoder
Copy link
Member

So, this is interesting. Two calls out then? :/

@RichiCoder1
Copy link
Contributor Author

Only when paging is used, and when it is, Count will be called once while List will be called multiple times with given constraints.

@RichiCoder1
Copy link
Contributor Author

I also discovered that the way we handle filtering out unlisted packages is straight up wrong when dealing with paging and count. Looking into fixing that.

@RichiCoder1
Copy link
Contributor Author

Hrmm. Chocolatey's nuget is out of date, even for v2. They added and explicit switch on search to handle delisted packages.

@ferventcoder
Copy link
Member

Hrmm. Chocolatey's nuget is out of date, even for v2. They added and explicit switch on search to handle delisted packages.

They also broke other things. That's why we are back on 2.8.2

@RichiCoder1
Copy link
Contributor Author

Hrmm. Chocolatey's nuget is out of date, even for v2. They added and explicit switch on search to handle delisted packages.

They also broke other things. That's why we are back on 2.8.2

Are you up to date with nuget-chocolatey too? It has the extensions I need to make this work efficiently. Failing that, I'm going to have to drop to a lower level and just build the query myself.

@ferventcoder
Copy link
Member

Take a look at the 2.8.2_adds branch and submit fixes there

@RichiCoder1
Copy link
Contributor Author

Yup, just realized I was looking at the wrong branch.

@RichiCoder1 RichiCoder1 changed the title Add Count to List Command API (GH-431) Add Count to List Command API Sep 25, 2015
@RichiCoder1
Copy link
Contributor Author

I was hoping that this wouldn't require a server change but it looks like NuGet's OData doesn't support datetime comparsions in it's IQueryable, and Chocolatey's server claims that IsListed doesn't exist. Server needs to either support an IsListed property or add isListed to it's search.

@RichiCoder1
Copy link
Contributor Author

nuget-chocolatey doesn't support searching against unlisted packages. Why was that check even there?

@RichiCoder1
Copy link
Contributor Author

So the isListed filter was completely superfluous unless I'm missing something. The results from the choco I just pushed return identical to the results from Choco v0.9.9.

Count now returns in an average of 1-2 seconds, and using Page is ever so slightly faster too.


public static int GetCount(ChocolateyConfiguration configuration, ILogger nugetLogger)
{
return SearchPackagesImpl(configuration, nugetLogger).Count();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

If you're wondering why I put Count() here, it's because I need IQueryable's Count. Otherwise it pulls down all the results, and gets the count of that.

@ferventcoder
Copy link
Member

I was hoping that this wouldn't require a server change but it looks like NuGet's OData doesn't support datetime comparsions in it's IQueryable, and Chocolatey's server claims that IsListed doesn't exist. Server needs to either support an IsListed property or add isListed to it's search.

We should add it.

nuget-chocolatey doesn't support searching against unlisted packages. Why was that check even there?

I was not aware that nuget could support searching against unlisted packages. Does it allow it?

@RichiCoder1
Copy link
Contributor Author

I was not aware that nuget could support searching against unlisted packages. Does it allow it?

Nope. That was me misunderstanding something.

@RichiCoder1
Copy link
Contributor Author

@ferventcoder developed a somewhat intelligent work around. Remote servers, aka OData chocolatey servers, seem to be very uniform and with my changes produce the same results. Other sources however behave....odd. So I now check if all the repositories we're searching against are remote. If they are, I let the server handle the heavy lifting. If not, we run the blocking filters that produce the correct results. The end result is --page and Count() are blazing fast against OData Servers, and produce the correct behavior elsewhere.

// Whether or not the package is remote determines two things:
// 1. Does the repository have a notion of "listed"?
// 2. Does it support prerelease in a straight-forward way?
// Choco previosly dealt with this by taking the path of least resistance and manually filtering out and sort unwanted packages
Copy link
Member

Choose a reason for hiding this comment

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

typo

@ferventcoder
Copy link
Member

Do you want to start squashing down/cleaning up your commits and adding the prepend (GH-431) and notes to the commits?

@ferventcoder
Copy link
Member

Example of what I'm looking for with commit summary and message body - e15c3eb

@RichiCoder1
Copy link
Contributor Author

Yup! Wanted to get something we're happy with before cleaning up my commits :)

@RichiCoder1 RichiCoder1 force-pushed the feature/Add_Count branch 2 times, most recently from 8d06218 to 5433f8d Compare September 28, 2015 16:05
@RichiCoder1
Copy link
Contributor Author

Squashed.

@RichiCoder1
Copy link
Contributor Author

(and fixed type now that I think of it)

@ferventcoder
Copy link
Member

I thought I saw at least two distinct commits in there. For squashing, I meant like the commit "Semicolon" and others

@RichiCoder1
Copy link
Contributor Author

Hows that?

@ferventcoder
Copy link
Member

Looks good! Now if there was some integration testing surrounding this, I wouldn't feel a need to manually test it. I'll pull it in for now and we can adjust if we need to later. :)

@@ -222,6 +222,15 @@ public IEnumerable<T> List<T>()
var runner = new GenericRunner();
return runner.list<T>(configuration, _container, isConsole: false, parseArgs: null);
}

public int Count()
Copy link
Member

Choose a reason for hiding this comment

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

Actually, the name of this throws me. It's not clear what this method returns.

This method needs some xml documentation with it as well (looks like I missed calling that out in the list command PR).

Copy link
Member

Choose a reason for hiding this comment

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

What about ListCount()?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hrmm. Normally I'd be against it, but I list ListCount works. Or rather GetListCount()

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

Copy link
Member

Choose a reason for hiding this comment

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

GetListCount sounds fine to. Count isn't clear on what it is doing, that's why I was hoping for more. It would be different if you were calling GetChocolatey().Setup().List().Count

@ferventcoder
Copy link
Member

Commit cleanup?

Richard Simpson added 3 commits October 3, 2015 17:45
… makes sense.

Updated Nuget List to attempt to use IQueryable all the way down for queries executed against service based repositories.
This allows chocolatey to defer filtering, sorting, and paging to the server rather than the client.
Reverts back to the old logic, though, for everything else.
Uses the IQueryable changes to add an efficient count for retrieving the number of results that would be returned by a list, usually in a much faster, more efficient way.
@RichiCoder1
Copy link
Contributor Author

Ohh, and we're all green again :D

Edit: Darn't teamcity.

ferventcoder added a commit that referenced this pull request Oct 7, 2015
@ferventcoder ferventcoder merged commit 2e72ad0 into chocolatey:master Oct 7, 2015
@ferventcoder
Copy link
Member

Thanks!

@RichiCoder1 RichiCoder1 deleted the feature/Add_Count branch June 3, 2016 22:45
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.

2 participants