Mamta Satoor wrote:
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
<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
<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));
I was working off the assumption from the following thread that
datavalue factory would provide the high level interface to get a dvd
based on format id and collate id. And if the work you describe above
is necessary it would be hidden behind the interface:
http://www.nabble.com/Should-COLLATION-attribute-related-code-go-in-BasicDatabase--tf3397113.html#a9583739
I'll look at building/using DataFactory interface. It will be some
additional overhead for straight path through store, but should be
minimal. Will need help in actual implementation of interface to
get right values - but I can submit an initial implementation that
just works for default collations first.
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]
<mailto:[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]>
> <mailto:[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)?
>
>
