Home

Request: Add options to temporarily override result limit? (per query and per dump)

Could this be added?

Not very often but occasionally I would have a query where I would want to output more results than the configured global limit (1000 by default). Usually for generating a report, the easiest way to get around it would be to write the contents of the query as a CSV file and analyze that. But sometimes I'd want the options that viewing in the results window would provide for these queries (e.g., generating a full diff between tables of data).

I could see me using this on a per query basis (add an option in the advanced tab for a query) and potentially on a "per dump" basis (add a "max results" option as an additional parameter or new method or overload). Might even be useful to apply to DumpContainer objects as well?

Comments

  • What do you think about a Util.MaxRowsToDump property?

  • I just worry of cases where the property gets changed during regular execution. How should we expect it to behave, especially with observables? Suppose an observable is dumped, the limit is changed, and another observable is dumped. Do they both take the latest limit or take the limit at the time it was created?

    If the intention is to be able to change the limit once, I would strongly prefer it to be an advanced setting for that particular query so it's clear it can not change as it runs. Many ways to confuse and abuse it to the point it would lead to undesirable behavior.

  • I support this! That would be really useful.

  • @JeffMercado - I understand your concerns. Although not perfect, Util.MaxRowsToDump does afford more flexibility than a query property, and is also very quick to implement. Regarding observables, the value applied would be the value of Util.MaxRowsToDump when dumped.

  • @JoeAlbahari said:
    This feature is available in 8.4.2:
    https://www.linqpad.net/linqpad8.aspx#beta

    Faster than Lucky Luke!

  • edited May 16

    Hey Joe, looks like a great new feature.

    Just to clarify, in addition to there being a static DumpOptions.Default setting, we also can pass that parameter to the .Dump() function itself? Similar to the way there's already an option to configure "depth". For most of my results, I'm happy with the default, but for one specific data set within the same query I only want up to max 100 rows. So, I can create a specific DumpOptions object for that dump, and the rest will use the default?

    Thanks,
    -Mike

  • Yes, you can provide a DumpOptions instance when calling Dump.

  • This is a very helpful new feature, thanks Joe! I also can't believe the coincidence of timing: I think of this as a useful new feature to suggest, only to find that someone suggested it 2 months ago and that it has already been implemented.

    I was also going to suggest something like DumpOptions, as the Dump() method overload was getting a bit out of hand, but I see is already in LINQPad 8 as well.

    (I was still using LINQPad 7 this morning, having overlooked the "new version" e-mails I'm sure I received at some point, but I upgraded right away when I realized that a) 7 was out of support; and b) my requested enhancements were already implemented in 8. BTW, the licensing/upgrade process for LINQPad is better than any other software I use; thanks for that as well.)

    FYI, my common use case for the MaxRows setting is when I'm doing a "data deep dive", trying to look at data from a number of sources and see how it fits together. Being able to quickly & easily view snippets from a number of lists/tables/arrays/etc. is very useful -- seeing a sample of the data from each and also being able to see the total count as well. Before MaxRows, the results output would be too long to be useful to scroll through, and dumping each list to a separate data table tab was a bit less convenient for viewing.

  • Thanks for the feedback!

Sign In or Register to comment.