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: how should store get an object based on format id and collation id?
Date Thu, 12 Apr 2007 01:35:21 GMT
If we decide to provide static interface on DataValueFactory, then the
Locale field and the RuleBasedCollator will need to be static too since we
the static interfaces will need access to RuleBasedCollator. Because of this
I am leaning more towards have non-static interface on DVF to get the
correct DVD. I wonder if store in it's boot method can get the
DataValueFactory with something like following
DataValueFactory dvf = (DataValueFactory) Monitor.bootServiceModule(create,
this, org.apache.derby.iapi.reference.ClassName.DataValueFactory,
startParams);
And then use this dvf to construct the DVD template row.

As for the DTSClassInfo, the earlier discussion on this topic (
http://www.nabble.com/Collation-implementation-WAS-Re%3A-Should-COLLATION-attribute-related-code-go-in-BasicDatabase--p9496608.html)
was to first just get the DVD based on the format id and then check if dvd
is instance of StringDataValue and if so, then call getValue on that dvd to
get collation sensitive implementations of character DVD classes. I copied
following from
http://www.nabble.com/Collation-implementation-WAS-Re%3A-Should-COLLATION-attribute-related-code-go-in-BasicDatabase--p9496608.html
if (dvd instanceof StringDataValue)
             dvd = dvd.getValue(dvf.getCharacterCollator(type));

BTW, I will add getCharacterCollator method on DVF when I am in there to add
RuleBasedCollator field.

Mamta


On 4/11/07, Mike Matrigali <mikem_app@sbcglobal.net> wrote:
>
>
>
> Mamta Satoor wrote:
> > Hi Mike,
> >
> > I think the code should go in iapi.types.DataValueFactory . DVF has
> currently DataValueFactory is an interface.  Do you have opinions
> about providing a static interface as is currently provided by
> the Monitor?
>
> > Locale of the database initialized on it by BasicDatabase using
> > setLocale method. I will go ahead and change that method to also
> > initialize a RuleBasedCollator field using the Locale field. This
> > RuleBasedCollator will be used to construct CollatorSQLChar and other
> > kinds of CollatorSQL... classes if the collation associated with format
> > id is not 0.
> >
> > Let me look at how actual objects are created using DTSClassInfo to see
> > how it might fit into the puzzle.
> the class is very straight forward, just take a look.  just a straight
> mapping of format ids to classes.
> >
> > thanks,
> > Mamta
> >
> > On 4/11/07, *Mike Matrigali* < mikem_app@sbcglobal.net
> > <mailto:mikem_app@sbcglobal.net>> wrote:
> >
> >     o The suggestion has been made to move the object creation
> >       stuff from montior to data type code.  Currently the monitor
> >       routines are called as static's off of a public class.  Should
> >       I create a similar "datatype" owned class or just move the
> >       code into the datatype factory and make store tote and pass
> >       around a datatypefactory reference where it needs it.
> >
> >     o In looking at implementation I see that actual objects get
> >       allocated by DTSClassInfo.getNewInstance() which is just
> >       based off of the format id.  I am wondering if the proposal
> >       is to change this behavior to something like
> >       DTSClassInfo.getNewInstance(collation_id)?
> >
> >
>
>

Mime
View raw message