Re: Type system notes

Thanks for the extended notes. These are very helpful.

> "Daniel John Debrunner" wrote:

>https://svn.apache.org/viewcvs.cgi/*checkout*/incubator/derby/code/trunk/ja
va/engine/org/apache/derby/iapi/types/package.html
>

>Generally the Derby engine works upon an array of DVD's that represent a
row

Are these same DVDs also then used by the log module to create log records?
>Interaction with Store
What interaction is there with other modules (or functionality) such as
log/restore/recovery or the catalog? Are external versions of type
descriptors used to create the catalog descriptions of the columns? Used in
metadata queries?

>DataTypeDescriptor
>Note that a DataValueDescriptor is not tied to any DataTypeDescriptor

Is this for the same performance reasons given in the DataValueDescriptor
section? There you said: 'For example in  reading rows from the store a
single DVD is used to read a column's value for all the rows processed'. I
assume that not tying the value and type descriptors together means that the
value descriptors don't need to validate the type when being reused during
reads from the store.

>Issues
>Interfaces or Classes
>Code would be smaller and faster if the interfaces were removed

Do you have any sense or 'guesstimate' as to what the maximum potential size
or speed savings could be?

Do you think this may be necessary (as opposed to desireable) for certain
environments such as mobile or wireless?

Is it conceptually possible to design a 'proof of concept' that might
provide at least an estimate of the savings that might be achieved? That is,
is there any specific test case that might be useful to see if it is worth
exploring further or would the changes be extensive even to perform a
limited test?. Obviously the simpler the case the better.

>Result Holder Generation
>The dynamic creation of result holders (see language section) means that
all operators have to check for the result reference being passed in being
null, and if so create a new instance of the desired type

Could a result holder cache/factory be used effectively for this? Perhaps a
separate thread that maintains a cache of new instances of various types.
The size of the cache could be configurable by introducing a new property.

This would allow the null checks to be removed from the operator code and
the operator code would not have to wait synchronously for instance
creation. Obviously there would be asynchronous waits since the cache would
never be big enough for large numbers of rows.