db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: Collation implementation WAS Re: Should COLLATION attribute related code go in BasicDatabase?
Date Tue, 20 Mar 2007 21:51:06 GMT
Mike, I am not sure if your question, about how in store DVD with correction
collation type is loaded, was answered or not. In other words, you had
question about following piece of pseudo code from Dan
     if (dvd instanceof StringDataValue)
             dvd = dvd.getValue(dvf.getCharacterCollator(type));

Let me attempt to answer it. It will help clear up things in my mind too and
make sure that I am understanding this correctly.

Currently, derby.impl.dtore.access.conglomerate.OpenConglomerateScratchSpacehas
get_row_for_export which first gets a class template row using
RowUtil.newClassInfoTemplate This method in RowUtil calls
Monitor.classFromIdentifier to get the InstanceGetter for each of the format
ids identified by store. Once
OpenConglomerateScratchSpace.get_row_for_export has the class template row,
it will call RowUtil.newRowFromClassInfoTemplate. This is the method, Dan is
proposing to modify, ie store should pass an additional array of int to
RowUtil.newRowFromClassInfoTemplate which will have the collation type
associated with the formatids of the template row.
RowUtil.newRowFromClassInfoTemplate will first get the DVD as it does today
using following
                    columns[column_index] =
(DataValueDescriptor) classinfo_template[column_index].getNewInstance();
In addition, it will need to do something like following
     if (columns[column_index] instanceof StringDataValue)
             dvd = columns[column_index].getValue(dvf.getCharacterCollator
(collationTypesForTemplateRows[column_index]));

Dan, let me know if I understood you right. This will help me answer your
question on the Derby wiki page
http://wiki.apache.org/db-derby/BuiltInLanguageBasedOrderingDERBY-1478 I
know that we don't need to get into the implementation code details in the
design phase, but I need to be able to picture this particular case in my
mind to understand where I am going.

thanks,
Mamta


On 3/15/07, Mike Matrigali <mikem_app@sbcglobal.net> wrote:
>
>
>
> Daniel John Debrunner wrote:
> > Mamta Satoor wrote:
> >
> ...
>
> >
> > - At recovery time the btree uses the collation type and the data value
> > factory to setup its template row array correctly. Something like
> >      for each dvd in row array
> >         if (dvd instanceof StringDataValue)
> >              dvd = dvd.getValue(dvf.getCharacterCollator(type));
>
> Note that the store issue is not just a recovery time issue, templates
> are required during normal runtime.  Creation of these templates used
> to show up (a long time ago) in performance analysis and work was done
> to optimize the performance.  So I am interested in making these
> template creations as efficient as possible.
>
> Your proposal above does not look right to me - it could just be I don't
> understand where the psuedo code is.  The code I expect in store would
> be something like below - letting the datafactory do whatever is right
> based on the format id and the collation, if store is going to "own"
> knowing
> the collation of a given column then I would expect something like:
>
> for each format id in row array
>     dvd = datavaluefactory.getObject(format id, character_collator_type)
>
> note this means extra overhead for every object creation in the template.
>
> To me it seems unfortunate to pass in this info per column, when at
> least in 10.3 the current code it is one per database.  I saw the
> direction as:
>
> o 10.3 only needs one collation per database so hide the info in the
>   datafactory, basically there is one DEFAULT collation per database.
>   Thus no need for second argument to datavaluefactory.getObject()
>
> o future release needs to have different collations per conglomerate,
>   then at that time we can store a collator type per conglomerate - we
>   have mechanism today to upgrade on the fly.  If we want to support
>   adding a collation to an existing database I would suggest continueing
>   the DEFAULT collation concept with some magic number representing
>   DEFAULT db collation in the datavaluefactory.getObject() call - which
>   would mean use db wide default rather than specify specific one. For
>   new databases we would not need default, we could at that time specify
>   one per conglomerate.
>   At this point we either change all the datavaluefactory.getObject()
>   calls to have 2 args and support DEFAULT_VALUE as second argument, or
>   maybe support both 1 and 2 arg calls - not sure.
>
> 0 future future release needs to have different collations per column,
>   then at that time we can store a collator type per column - we
> continue to have mechanism to upgrade on fly as long as we can come up
> with a default value for old tables.  Same issues as above.
>
>
>
> >
> > - setting the collation property remains in the data dictionary
> >
> > - basic database sets the locale for the DataValueFactory after it boots
> > it, using a new method on DVF
> >         void setLocale(Locale locale);
> >
> > I think approaching the problem this way will lead to a cleaner solution
> > in the long term and be somewhat easier to implement.
> >
> > Thanks,
> > Dan.
> >
> >
> >
> >
> >
> >
>
>

Mime
View raw message