Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Sat, 2 Jul 2005 00:48:57 +0200

Hi,

First of all: I finished my example and have put it on the wiki. See V4 
Database Access -> V4 Design: Assembling Record Support

On Friday 01 July 2005 15:18, Kay-Uwe Kasemir wrote:
> On Jun 30, 2005, at 20:37, Benjamin Franksen wrote:
> > On Thursday 30 June 2005 17:47, you wrote:
> > o what if there is no 'value' (see a recent posting on core-talk, I
> > believe it was from Andrew)
>
> Sure, there are records where adding a user-defined 'average'
> field doesn't make sense.
>
> But then with your more elaborate idea of replacing predefined
> records with record building blocks, wouldn't you get the same
> issue where some building blocks are simply not meant to be combined?

Sure, not everything combines or is even meant to combine. But with 
building blocks you don't get the same issue because the record type 
designer decides what to use and what not. My example is the IVOV/IVOA 
block: Surely this makes sense only for output records. OTOH, maybe 
you'll dind a use for it in record types that are more complex than the 
standard xxxOutRecords. For instance, nothing prevents you from 
duplicating struct(invalidOutput) inside the same record type, for 
instance if you have two output links, or even put many more of them 
into an array field.

> > o what does smoothing do if the value exists but is an array. Or an
> > integral type. Or a string?
>
> What should the calc record do if all its inputs are strings or
> arrays? Again you have ample opportunity to create useless databases.

True. Note however, that string fields /can/ contain valid numbers and 
in this case will be converted to numbers if possible.

> With user-defined fields, you could actually create
> specific 'average' fields to determine the average length of a string
> or the average value of elements in an array or ...,
> just like your building blocks could offer similar pieces
> which are meant to go only with scalar, array, string, ... records.

So how do you propose to associate the code that belongs to a certain 
entension (and implements all this nice dynamic behavior) with the 
extra field and the record support?

> >>> Thus, I argue for abandoning the idea to have per-instance
> >>> defined fields. Instead, ..... create a new record type.
> >>
> >> ....I'll try to present an example on the wiki.
>
> I think that's very helpful. I like the general idea of
> record building blocks, I just don't see an efficient way to get
> there.

Done. It is, btw, extremely efficient, that is, there is no more 
overhead than a single function call. The code is even tested... :-) I 
can send a tar-ball of all files if you (or others) are interested.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System