Should we check nil pointer query in dataselect

[warjiang]

What would you like to be added?

The dataselect is well designed to filter、sort、paginate datacells. I want to reuse the dataselect module in my project. But I metioned that FilterQuery、SortQuery、PaginationQuery may be nil and cause panic error, for example

// Filter the data inside as instructed by DataSelectQuery and returns itself to allow method chaining.
func (self *DataSelector) Filter() *DataSelector {
	filteredList := []DataCell{}

	for _, c := range self.GenericDataList {
		matches := true
		for _, filterBy := range self.DataSelectQuery.FilterQuery.FilterByList {
			v := c.GetProperty(filterBy.Property)
			if v == nil || !v.Contains(filterBy.Value) {
				matches = false
				break
			}
		}
		if matches {
			filteredList = append(filteredList, c)
		}
	}

	self.GenericDataList = filteredList
	return self
}

when we iterate self.DataSelectQuery.FilterQuery.FilterByList, if the FilterQuery is nil, it will panic.

The use-case of my code is following:

selectableData := dataselect.DataSelector{
    GenericDataList: ToCells(listResult.Items),
    DataSelectQuery: &dataselect.DataSelectQuery{
	//FilterQuery:     nil,
	//SortQuery:       nil,
	//PaginationQuery: nil,
	//FilterQuery:     dataselect.NewFilterQuery([]string{"name", "111"}),
	SortQuery: dataselect.NewSortQuery([]string{"a", "name"}),
	//PaginationQuery: dataselect.NewPaginationQuery(10, 2),
    },
}
selectableData.Filter().Sort().Paginate()

Apart from QueryFilter, the DataSelectQuery should also be checked to avoid nil pointer error.

Why is this needed?

For more robust, when the dataselect pkg is resued by other project.

### Tasks

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[maciaszczykm]

@warjiang are you willing to work on it?

[warjiang]

@warjiang are you willing to work on it?

Yes, I think it should check the nil pointer, but no repsonse or no more discussion about it. Should I make contribution and ask for some review the changes?

[maciaszczykm]

@warjiang Yes, that would be perfect.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.