[fdo-internals] Counting rows in managed IFeatureReader

Wed Apr 23 09:20:30 EDT 2008

Hi Orest,

Actually, I was thinking of Count() avoiding duplicate selects by cloning
once-instantiated internal reader object, saving a roadtrip to server (which
is, naturally, an overkill). I'm already doing it on managed level, but I'm
not sure how managed object clones relate to their unmanaged twins
underneath (you know, managed bindings disposing patterns and other obscure
stuff) :-) Why do you think that another instance (not reference) of a
reader, a copy of it actually, would affect the original?

I thought it would be nice to be able to inspect total count of features
being fetched via ISelect, before processing actual reader contents. Another
thing - ISelect is supported by every provider, and I need a generic
solution. I'm using it heavily during both reader instance pre-processing
and in-processing (i.e. progress bar, counters)... 

Regards,
Maksim Sestic

Orest Halustchak wrote:
> 
> Hi Maksim,
> 
> I think the point around performance issues with Count() on the feature
> reader is not related to side effect if it isn't used but that if it is
> used it may be much less efficient than using Count() with Select
> Aggregates which may use a native Count() implementation. Selecting all
> the records just to get a count and then selecting them all over again is
> duplicated processing.
> 
> Making an internal copy of a reader may be more of an issue than a simple
> clone of that reader object. The reader is generated as a result of the
> execution of a select. If you start reading through the results of the
> reader, to be able to start reading again, in most cases it means the
> provider needs to re-execute the select (exception may be providers that
> support a scrollable reader, but not all have that sort of capability).
> You can re-execute the select yourself and will get a separate reader.
> 
> Could you explain your application scenario where you need this ability
> and maybe we can think of other alternatives?
> 
> Thanks,
> Orest.
> 
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
> Sent: Tuesday, April 22, 2008 8:02 AM
> To: fdo-internals at lists.osgeo.org
> Subject: RE: [fdo-internals] Counting rows in managed IFeatureReader
> 
> 
> Hi Barbara,
> 
> I'm aware of it, but 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:
> 
> If Not reader.IsEmpty
>    Dim cnt As Integer = reader.Count
> ...
> End If
> 
> 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.
> 
> Robert's proposal is OK, but the downside is that SelectAggregates can't
> lock the records being fetched.
> 
> Regards,
> Maksim Sestic
> 
> 
> 
> Barbara Zoladek wrote:
>>
>> Maksim,
>> Adding Count to IFeatureReader will have performance side effects. There
>> is no way to find out the number of rows without either fetching all the
>> rows or explicitly executing something like 'select count(*)' .
>>
>> Robert's suggestion looks better.
>>
>> Thanks,
>> Barbara.
>>
>> -----Original Message-----
>> From: fdo-internals-bounces at lists.osgeo.org
>> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
>> Sent: Thursday, April 17, 2008 2:56 AM
>> To: fdo-internals at lists.osgeo.org
>> Subject: RE: [fdo-internals] Counting rows in managed IFeatureReader
>>
>>
>> Thanks for the tip, Robert. I need to use ISelect because of locking
>> (which
>> is not supported by ISelectAggregates).
>>
>> I'd suggest that generic IFeatureReader (neverthless of provider
>> involved)
>> expose two additional readonly properties:
>>
>> 1) Count - creates internal copy of a reader and traverses it, returning
>> total number of feature instances found in it.
>>
>> 2) IsEmpty - boolean returning True if reader has no features instances
>> in
>> it, False otherwise.
>>
>> Regards,
>> Maksim Sestic
>>
>>
>>
>> Robert Fortin wrote:
>>>
>>> Maksim,
>>>
>>> You can use the IselectAggregate command with the COUNT function to
>>> retrieve the number of rows for a given class.
>>> This will ensure that you use the optimize implementation of the native
>>> data source to retrieve the number of row where it is available.
>>>
>>> Robert Fortin
>>>
>>> -----Original Message-----
>>> From: fdo-internals-bounces at lists.osgeo.org
>>> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Maksim
>>> Sestic
>>> Sent: Wednesday, April 16, 2008 6:11 AM
>>> To: fdo-internals at lists.osgeo.org
>>> Subject: [fdo-internals] Counting rows in managed IFeatureReader
>>>
>>>
>>> Hi all,
>>>
>>> Since IFeatureReader doesn't provide Count property for total number of
>>> records in it, what's the most "proper" way to get it out from managed
>>> IFeatureReader? I'm asking this because of necessity to explicitly close
>>> a
>>> reder after it's returned from, say, ISelect command. How do I get a
>>> safe
>>> copy of instantiated managed IFeatureReader object to count it's
>>> properties,
>>> without affecting the original one?
>>>
>>> It would be a no brainer if IFeatureReader was fully implemented in
>>> .NET,
>>> but managed bindings always make me wonder if unmanaged resources get
>>> disposed in a proper way.
>>>
>>> Regards,
>>> Maksim Sestic
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Counting-rows-in-managed-IFeatureReader-tp16720338s18162p16720338.html
>>> Sent from the fdo-internals mailing list archive at Nabble.com.
>>>
>>> _______________________________________________
>>> fdo-internals mailing list
>>> fdo-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>>> _______________________________________________
>>> fdo-internals mailing list
>>> fdo-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Counting-rows-in-managed-IFeatureReader-tp16720338s18162p16739953.html
>> Sent from the fdo-internals mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> fdo-internals mailing list
>> fdo-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>> _______________________________________________
>> fdo-internals mailing list
>> fdo-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>>
>>
> 
> --
> View this message in context:
> http://www.nabble.com/Counting-rows-in-managed-IFeatureReader-tp16720338s18162p16823821.html
> Sent from the fdo-internals mailing list archive at Nabble.com.
> 
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> 
> 

-- 
View this message in context: http://www.nabble.com/Counting-rows-in-managed-IFeatureReader-tp16720338p16834596.html
Sent from the FDO Internals mailing list archive at Nabble.com.