[ALL] let's think about Query Language for 2.0

[Keith DeLong]

Hi Ruslan,
 
>> One last thing that would be incredibly powerful -- what if Result could be
>> set as a standard RB array, collection or dictionary. The power to return a
>> data query directly into these objects (that are supported and expanded by
>> RS) would be awesome.
> 
> Well, similar functionality we have for V4MD and V4WS.
> 
> In this products, developer can ask Valentina put few records of Cursor into
> e.g. property list.
> It seems exists way ask result as list without cursor at all.
> 
> Why you think this will be "powerful" feature?

I often put a vCursor into an RB object to separate the dataset the result
from the database. I may populate an array, a collection, dictionary or
listbox. I've often wished the result went directly into the object for
speed purposes.  

As I think about it -- with a separate V4RB client from server -- not
display result sets can be left in a vCursor and not worry about the
database. Especially if we can designate cursors as read only or read/write.

This refutes part of my thinking...
 
> Note, that Valentina will need build RB array at first, then return it to
> you. May be RB will be able do this really fast...probably yes.
> 
> But what this brings to you?
> I mean having of result as Array or Collection?

Actually I've been thinking mostly of dictionaries. I've been toying with a
wrapper 'Result dictionary' to load from a vCursor. Here's the most recent
structure I'm experimenting with:

  Result Dictionary
    The Key/Value Pairs are Order and Fieldname  //order = column number
    
    Properties     
        Field1 as Dictionary
            The Key/Value Pairs are Row and Value
        Field2 as Dictionary
            The Key/Value Pairs are Row and Value
        Field3 as Dictionary
            The Key/Value Pairs are Row and Value
        Etc...

Here's the power as I ponder:
(1) Because dictionaries use hash tables, I can write functions that find
random values and tell me if a random value is in a table nearly
instantaneously independently of the data set size. The idea is that I no
longer have to sequentially loop through the data in a cursor.

(2) Dictionaries hold variants so I can load each field dictionary with its
native data type. This has all sorts of implications for using data one
moment and viewing it the next. If I need all strings, the conversion of
variants in by RB seems fast and transparent.

(3) I've segmented the data in a logical way for me -- I can build methods
that subloop through just the Field names, the individual field
dictionaries, etc. with great ease.

Is there any merit to this idea or am I just abusing dictionaries as data
containers??  :-)

Keith DeLong