Opened 17 years ago
Last modified 16 years ago
#309 new enhancement
Add two additional IFeatureReader properties: Count and IsEmpty
Reported by: | MaksimS | Owned by: | gregboone |
---|---|---|---|
Priority: | minor | Milestone: | 3.4.0 |
Component: | FDO API | Version: | 3.2.0 |
Severity: | 3 | Keywords: | |
Cc: | External ID: |
Description
IFeatureReader should expose two additional readonly properties:
1) Count - returning total number of feature instances found within IFeatureReader. It actually creates an internal copy of a reader and traverses it to get the result, while original reader object stays intact.
2) IsEmpty - returns True if reader has no feature instances in it, False otherwise.
Change History (4)
comment:1 by , 17 years ago
comment:2 by , 16 years ago
I agree on this matter. There is no real nice way to find out if a schema has data in it to start the ID number process.
comment:3 by , 16 years ago
On a side note you can find the isempty status by checking the ture/false of the ReadNext(). Example shows false if the schema is empty.
IFeatureReader ifeaturereader = selectCommand.Execute(); MessageBox.Show(ifeaturereader.ReadNext().ToString());
Having a count or a way to get the max number of the ID field would be nice for manual based primary numbering reasons still.
comment:4 by , 16 years ago
I thought it was just more convenient (and takes less time after all), since both IsEmpty and Count were ment purely for pre-processing purposes (I mean - before the first ReadNext is issued over the Reader). Anyway, after some rather interesting discussion on Internals about this ticket, I still don't quite comprehend the reason of why IFeatureReader can't have these extra properties implemented. Presumably, the guesswork of determining the Count value is on providers themselves.
Count would not get calculated on IFeatureReader instantiation (i.e. via ISelect.Execute). The property would act as a function, when explicitly called (get). If called, it should create an internal copy of underlying reader, traversing it to return total number of feature instances. If it's not calculated on IFeatureReader instantiation then there're no performance side effects. A private member could be used for storing once-calculated features count for faster consequent calls to Count() function of the same instance of IFeatureReader.
Now, why IsEmpty when there's a Count? Because IsEmpty traverses only the first record of possibly many records, returning False if ReadNext doesn't return Nothing. IsEmpty() works on the same premises as above described Count() mechanism.
So user can chain calls to get the results with less overhead:
I think that it's better to have it implemented on unmanaged tier, since doing it using managed bindings may sometimes lead to unexpected results.