db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Collation implementation WAS Re: Should COLLATION attribute related code go in BasicDatabase?
Date Tue, 20 Mar 2007 22:44:37 GMT

Mamta Satoor wrote:
> 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.OpenConglomerateScratchSpace has 
> 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]));

My opinion is that this work should be done in the datavalue factory and 
not outside.  Dan suggested at one point that some of the work of 
generating classes/instances should move from Monitor to datavalue factory.

  So I was assuming something like RowUtil.newClassInfoTemplate instead 
of calling Monitor.classFromIdentifier(format_ids[i]) get an array of
InstanceGetter's, it would call something like
datavaluefactory.classFromIdentifier(format_ids[i], collator_ids[i]) -
then every InstanceGetter would produce the right type with collator set
from then on.

Internal to dvf it can do the work of checking for instanceof if it 
needs to, but because it is inside dvf maybe it can do something smarter .
> 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 
> <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 
> <mailto: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.
>      >
>      >
>      >
>      >
>      >
>      >

View raw message