Skip to main content

RowFilter again: tension between minimal api and ease-of-use?

2 replies [Last post]
kleopatra
Offline
Joined: 2003-06-11
Points: 0

same question posted over at OTN
http://forums.oracle.com/forums/thread.jspa?threadID=1553773&tstart=0

for your convenience, copied here:

Hi experts,

(yeah, I'm still struggling with RowFilters ;-)

The minimal api I'm referring to is ComparisonType: it has values before, after, equal, not-equal. This is complete in that comparisons like before-and-equal can be expressed by a logic not-after.

An important aspect of ease-of-use (as I see it :) is consistency: learn one pattern, way-of-life, dialect .. and re-use incomparable contexts. Now the pattern to use a RowFilter on comparables is

<br />
RowFilters.compareFilter(Before, comparisonValue, index);<br />

Obviously, that pattern can't be used for comparisons like "compound" comparsions:

<br />
// ease-of-use-version, can't be done<br />
RowFilters.compareFilter(Before-And-Equal, cv, i);</p>
<p>// instead have to break the habit<br />
RowFilter after = RowFilters.someFilter(After, cv, i);<br />
RowFilters.notFilter(after);<br />

hmm ... now in a framework I could hide the two-line effort behind a factory method

<br />
RowFilters.beforeAndEqualFilter(cv, i);<br />

here the type of comparison is drawn out of the parameterlist into the method name. For a consistent api, that factory would have to have cover methods beforeFilter, afterFilter ... etc.

An alternativ approach would be to have a new ComparisonType (unfortunately, it's an enum - not extendable) with all combinations and re-implement the comparing filters. BTW, the latter is necessary anyway, as it should be applicable to all Comparable.

Hmm ... (incoherent?) mumblings, mainly because I can't really make up my mind ;-) Opinions, please?

Thanks
Jeanette

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kleopatra
Offline
Joined: 2003-06-11
Points: 0

and now ... on the ranges: between and not-between. What about the "most natural" inclusion strategy for the boundary values: include or not include? JIDE includes them without options to configure selective exclusion.

Opinions, please?

kleopatra
Offline
Joined: 2003-06-11
Points: 0

got a suggestion (over at OTN) which feels "simply right" :-)

Thanks
Jeanette