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 <[EMAIL PROTECTED]> 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* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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)? > >
