On Jan 11, 2010, at 9:23 AM, David Avendasora wrote: Hi Aaron! In summary, it doesn't matter if you "fix" the DB or you fix the in-memory sorting as we have done. What matters is that you realize there can be differences and you have full control over how you want sorting to work no matter what DB you use.
I agree completely. Sorting nulls isn't technically valid in the first place but in practical terms you need to do something with them. Since we have conflicting needs, I think we should come up with a property that will define how nulls are sorted so that both your solution and a DB-specific one (if available) are triggered based on the preference.
something along the lines of: nullSortOrdering=first/last
What do you think?
Based on your email, I will update the Jira PATCH ticket I submitted to hold off on applying it so we can better address this.
Dave
It definitely makes sense to use a property here. We should be explicit, though, about a few edges.
- If the property is not set, does the memory sorting behavior automatically inherit the default behavior of the database? Presumably yes.
- If the property is set and the default behavior of the database is different than the property and there is no way to tell the database to switch the behavior (such as when an adaptor or driver does not read a connection dictionary value for this), does the code just warn, or throw an exception?
JDBC does require the DatabaseMetaData object to implement a nullsAreSortedHigh() and nullsAreSortedLow() method, but the spec does not actually say anything about them. For example, we could assume that the values returned from the two methods are different from each other and constant for the life of a connection, but the spec does not say that. And we have data sources that are not JDBC. We should at least be specific about what should happen with an uncooperative data source.
cheers - ray
|