RE: WITHDRAWN: Re: No meeting today, Wednesday 26th.

[<jam...@di...>]

> -----Original Message-----
> From: Marty Kraimer [mailto:mrk...@co...]
> Sent: 26 October 2011 12:39
> To: epi...@li...
> Subject: Re: WITHDRAWN: Re: No meeting today, Wednesday 26th.


 
> Looks like it might work.
> We do have to allow for things like:
> 
> structure table {
>      structure [] columns {
>          structure column {
>              string name
>              byte type_tag
>              string [] stringvalue // all but one of these columns are
> zero length but we only waste a byte for each
>              int [] intvalue
>              alarm_t[] alarmValue
>              ...
>          }
>      }
> }
> 
> But this seems OK.
> For an sql insert this seems to work.
> 
> > I know I've mentioned this before but this has the additional benefit of
> removing the need for channelRPC altogether (putget is enough). To put this to
> rest, what's the minimal counter-argument?
> >
> 
> I think that having to support columns like "alarm_t[]" means that
> channelRPC is still needed.
> 
> Lets consider some of the examples Greg gave for table.
> In his examples the client gives a search string and gets back a table
> where:
> 
> 1) The number of columns are unknown but determined by the search
> 2) The type of each column is unknown but determined by the search
> 3) The number of rows is unknown but is determined by the search AND is
> the same for every column.
> 
> Thus it has the form something like
> 
> structure table
>      // some generic info
>      someType[] col0
>      someType[] col1
>      ...
> 
> I think this still needs channelRPC.
> 
> 
> Marty
> 

The tagged union approach only works if the possible list of column types are known in advance. If we only allow our fixed list of normative types then there isn't a problem.

Note that this kind of encoding is what JDBC connectors will use internally (I'm saying that without direct evidence but if you look at 
Qt QSQLQuery rows are returned as a list of QVariants (tagged unions))

http://doc.qt.nokia.com/stable/qsqlquery.html


-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom