Sets from Cursors Re: VCursor.AddRecord

[Ed Kleban]

On 12/3/05 2:27 AM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 12/2/05 5:54 PM, "Ed Kleban" <Ed at Kleban.com> wrote:
> 
> Hi Ed,
> 
>>> Cursor must be ReadOnly = false
>>>  
>>> In fact, such cursor do not have own records. It work over original
>> 
>> Which cursors do not have their own records?
>> ReadOnly = false cursors?
>> or all cursors?
> 
> Not all. 
> 
> Cursor -- is RESULT of SQL query SELECT.

Yes, of course.

> You can note that SELECT can be on SINGLE table or to few tables.
> 
> Single table SELECT return you cursor which you you can modify.
>     it have no own records AT LEAST right now. Future we can add options.

Nice to know, but its unlikely I'll ever want to modify a cursor obtained
this way.

> Few table cursor (JOIN) -- is READ ONLY cursor.
>     a) simple joins do not require new table
>     b) e.g. GROUP BY do
> 
> You as Develop actually should not care if exists tmp table or not.
> Only you can check: if cursor is read only or no.

Ah!  Good to know. I missed that point.  So you can test whether the cursor
is ReadOnly when you get VCursor back from the SQL search, and its state
will depend upon the nature of the request you made.  I understand.
 
>> Essentially you're telling me that the cursor you get back when readonly =
>> false is internally a bitSet or an ArraySet.
> 
> It is MORE COMPLEX structure than ArraySet,
> But yes it do USE ArraySet
>  
>>    Is there a technical reason why you could not provide the functions:
>> 
>>        VCursor.AsArraySet() as VArraySet
>>        Vcursor.AsBitSet() as VBitSet
> 
> No. 
> 
> Just they should be used only for single table cursor.
>  
>> Which is different from the question:
>> 
>>    Is there a philisophical reason why you would NOT like to provide these
>> functions?
> 
> In Mantis exists such request.
> 
> Or ... In was request to add ability convert
>     ArraySet into Cursor...and this is more hard, because also it needs
>     specify fields...and I do not see huge advantage...
> 

I see no benefit to this.  My goal is to go from Cursor to VSet (Bit and
Array) so that we can take advantage of the faster API FindXxxx calls for
post-processing.

 
On 12/3/05 2:58 AM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> 
> TIP:
> 
> If you KNOW that you will find few records (1%)
> 
> Then it is better use ArraySet.

Yes, of course.  Good advice.


On 12/3/05 2:59 AM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 12/2/05 7:52 PM, "Ed Kleban" <Ed at Kleban.com> wrote:
> 
>> Now it may turn out that Ruslan will end up telling us this is foolish,
>> because no matter how much less efficient SQL is compared with the API
>> calls, that the overhead of Creating, Parsing, and running a single SQL call
>> is so minimal that you're far better off investing the time in letting SQL
>> do all the work in a single query.  That may be true, but I'd like to hear
>> him chime in on the topic.  I always learn good things when he does.
> 
> Noooooooooooooooo
> 
> If SQL is best of the best, then why you think we have ad in v2 API methods?
> :-)

That's quite a loud chime :)   Ok. Then I'll take that as agreement that
there is merit to this idea and will add a Manits request to provide
conversion from a VCursor to ArraySet and BitSet -- at least for Cursors
derived from a single Table as indicated by VCursor.ReadOnly = false.


On 12/3/05 3:02 AM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 12/2/05 8:35 PM, "Sims, John" <ayu8 at cdc.gov> wrote:
> 
>> You know, as I'm typing here, it has occurred to me that Vset has
>> Append/Remove methods so we could really just do this ourselves (though,
>> performance-wise, probably not as fast as Ruslan could implement).
> 
>> But,
>> we could extend Vcursor (I'm pretty sure you are an RB guy) and add a
>> ToBitSet and/or ToArraySet method ourselves.
> 
> I think here problem. Db.SqlSelect still will return you Vcursor,
> But not yourCursor
> 
> More correct design here to use -- algorithms.
> Methods which accept Vcursor

Ah!  You mean change the Vfield.FindXxxx commands so that they will accept a
VCursor as well as accepting a VBitSet or VArraySet for inSelection?  Yes,
that of course would be optimal... but also a lot more work to add I'm
guessing.
 
> But of course it is better move this into plugin, C++ code
> 
 

On 12/3/05 3:28 AM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 12/2/05 11:09 PM, "Ed Kleban" <Ed at Kleban.com> wrote:
> 
>> Technical sense? yes.  Practical sense? no.   Efficiency is the name of the
>> game here.  I have no interest in manually building a VSet through a
>> tortuously slow procedure just so I can have the benefit of passing it to a
>> function that can use it rapidly.  Far better to just write the more
>> complex SQL or iterate through the cursor and be done with it.
> 
> Btw, I have realize only now
> 
> Vcursor already keep ArraySet, so it will take ZERO time to give you that
> ArraySet. And no Additional RAM.

Very good!  And presumably minimal coding as well if you simply provided a
single additional method:

    Vcursor.GetArraySet( ) as VArraySet
    // Returns nil if VCursor.ReadOnly is true

> But come issues as:
> 
>     what todo if you will start add items into ArryaSet.
>     well legal steps ..

In the short term, you just document the fact that "If you add items to an
ArraySet you get from VCursor.GetArraySet then horrible things will happen
that you will regret for the rest of your life."

In the long term, you just add an internal flag on ArraySets to note that it
is "Locked" and cannot be extended.
 
Very good.  I'll added Mantis request #0001170 for this.


Thanks for the fine replies.

--Ed