[fdo-internals] SQLite select ordering not working

Haris Kurtagic haris at sl-king.com
Sat Jul 17 13:02:56 EDT 2010


Yes, I understand you. My second point was not about that bug in
provider ( i saw it is minor bug and fix), I was more pointing toward
how it was used in some fdo client.

Haris

On Sat, Jul 17, 2010 at 6:40 PM, Traian Stanev
<traian.stanev at autodesk.com> wrote:
>
> Ordering works fine if you use the extended select way of setting it. We'll fix the bug, that's why I said "temporary" workaround. It's just an oversight from when I implemented it, I was probably confused by there being two ways to set ordering in the IExtendedSelect interface.
>
> Traian
>
>
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
> Sent: Saturday, July 17, 2010 3:25 AM
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] SQLite select ordering not working
>
> In MapGuide ordering doesn't work either for SQLite, I think I have
> been told so.
>
> Could be that it works in autocad map but if it is true that worries
> me even more because it sounds like inconsistency in use of fdo in our
> most important client :).
>
> I was planning to use what I think is correct logic:
> if provider doesn't support selectordering  then use extendedselect if
> supported by provider.
> But as it is now, that will be correct for SDF (selectordering=false)
> but not for SQLite (selectordering=true) provider.
>
> For our use case I will fix provider rather then to hard code casting
> for sqlite provider.
>
> Thanks,
> Haris
>
> On Sat, Jul 17, 2010 at 2:47 AM, Traian Stanev
> <traian.stanev at autodesk.com> wrote:
>>
>> Actually I see what you mean, yes, there is a bug for regular ISelect, in case you use SetOrderingOption(ordering), rather than SetOrderingOption(name, ordering), with the former having a blank implementation -- a temporary workaround would be to cast the command to extended select and use SetOrderingOption(name, ordering). I guess everybody has been using the extended select for ordering so far, so we didn't notice the problem with regular select.
>>
>> Traian
>>
>>
>> -----Original Message-----
>> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
>> Sent: Friday, July 16, 2010 8:34 PM
>> To: FDO Internals Mail List
>> Subject: RE: [fdo-internals] SQLite select ordering not working
>>
>>
>> Hi Haris,
>>
>> SltExtendedSelect already implements GetOrderingOption and SetOrderingOption. Can you show a code snippet that triggers the problem?
>>
>> Traian
>>
>>
>> -----Original Message-----
>> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
>> Sent: Friday, July 16, 2010 5:55 PM
>> To: FDO Internals Mail List
>> Subject: [fdo-internals] SQLite select ordering not working
>>
>> Hi,
>>
>> I haven't tried myself but heard from colleagues that SQLite ordering
>> is not working for FdoSelect command.
>>
>> I looked at SQLite code and  there is SltExtendedSelect which
>> surpassingly implement both FdoSelect and FdoExtendedSelect.
>>
>> I believe bug comes from function (SltCommands.h line 116)
>>       //Regular select -- not scrollable
>>        virtual FdoIFeatureReader*          Execute()
>>        {
>>            std::vector<NameOrderingPair> ordering;
>>            if (m_orderingProps)
>>            {
>>                for (int i=0; i<m_orderingProps->GetCount(); i++)
>>                {
>>                    FdoPtr<FdoIdentifier> id = m_orderingProps->GetItem(i);
>>                    ordering.push_back(NameOrderingPair(id.p,
>> m_orderingOptions[id->GetName()]));
>>                }
>>            }
>>            return m_connection->Select(m_className, m_filter,
>> m_properties, false, ordering);
>>        }
>>
>> which is using m_orderingOptions. Those properties are only set trough
>> FdoExtendedSelect interface not for FdoSelect.
>>
>>
>> So if I am right then fix is to change line to:
>> ordering.push_back(NameOrderingPair(id.p, GetOrderingOption());
>> and also to implement GetOrderingOption() and SetOrderingOption() functions.
>>
>> This bug would not happened if select and extendedselect would be
>> implemented in their own separate implementations.
>> In general I would consider problematic that extended select
>> implementation is returned for select interface too.
>>
>>
>> Haris
>> _______________________________________________
>> 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
>> _______________________________________________
>> 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
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>


More information about the fdo-internals mailing list