# A fluid.datasetfilter~ object for conditional querying **URL:** \ **Category:** Toolbox 2 Improvement Ideas\ **Created:** [July 21, 2020, 9:52am UTC](https://discourse.flucoma.org/t/a-fluid-datasetfilter-object-for-conditional-querying/598 "2020-07-21T09:52:09Z")\ **Posts on this page:** 1\ **Showing post:** 29

**Author:** ![weefuzzy](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/weefuzzy/32/362_2.png) [@weefuzzy](https://discourse.flucoma.org/u/weefuzzy)\ **Post date:** [September 28, 2020, 9:00am UTC](https://discourse.flucoma.org/t/a-fluid-datasetfilter-object-for-conditional-querying/598/29 "2020-09-28T09:00:19Z")

I think we’re maybe at cross purposes about rows / cols? > [@](#): > > an entrymatcher interface where it wouldn’t matter if there was a new column inserted in certain descriptor/set (e.g. pitch[4] becoming pitch[5]) with regards to everything else in the dataset. `entrymatcher` seems not to support varying the size of entries (and their labels). The number of columns is set when the object is created, and sending `names` with the wrong size list gets you an error. I don’t see how what you describe can be done, unless you mean adding a new entry… > [@](#): > > Or I guess something like a dict / coll where the order of the data inside doesn’t matter, only what you decide to call vs, um… a buffer~ where index 3 = index 3 regardless of whatever you want to call it. Again, the things that don’t matter for dict / coll are the labels for entire entries. Neither has a concept of labels for individual indices within an entry. `fluid.dataset~` is _exactly the same_ in this regard. You can insert / delete whatever you want, the relationship between individual rows ( = points = entries) is maintained. buffers, meanwhile, are abstractions that represent a single row/point/entry; just like a list (which also has no label indexing). What we’ve been dealing with in the last few posts are labels for the individual indices of a point in `fluid.datasetquery`. I’m not completely clear on how the scheme suggested above does less than the equivalent labelling in `entrymatcher`. Maybe what’s confusing is that `entrymatcher` encapsulates stuff that is spread across different objects for us: it fulfils aspects of `fluid.dataset~` (entries of uniform width, recallable by label), `fluid.datasetquery~` (filtering entries by criteria against individual columns) and `fluid.kdtree~` (recalling sets of entries based on distance). --- _[View the full topic](https://discourse.flucoma.org/t/a-fluid-datasetfilter-object-for-conditional-querying/598)._