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 Fri, 13 Apr 2007 19:13:03 GMT
Hi Mike,

I didn't quite understand following
*****************Mike wrote**************
2) using existing dvd's class to get a new "empty" dvd that matches it
   (which is why it does not call clone).
   dvd = dvd.getClass().newInstance()

   o less sure about this one.  Seems like we need a new dvd interface
     that does the equivalent thing.  I believe the original code got
     here because the original store code did not deal with DVD's it
     just got objects, so could not make dvd calls.  There is a
     getNewNull() interface, anyone know if there is any runtime work
     that would be saved over this by creating a
     getNewEmpty() interface?

    dvd = dvd.getNewEmpty();
******************************************
What I think you are saying is
"There is someplace in the Derby code, where we do
dvd.getClass().newInstance().
And the reason it is done this way is that the calling code does not know
that it is dealing with a dvd object. Maybe that code can now check if it is
dealing with a StringDataValue and if so, then have the code call
dvd.getNewEmpty which will be defined only on StringDataValue. The
getNewEmpty() method will copy the RuleBasedCollator info to a new instance
of StringDataValue and return that." Did I understand you right? Also, I am
just curious where is this code dvd.getClass().newInstance() right now?

thanks,
Mamta

On 4/12/07, Mike Matrigali <mikem_app@sbcglobal.net> wrote:
>
>
>
> Mamta Satoor wrote:
> > Mike, the following code will be part of DataValueFactory and hence it
> > will be part of the interface. Please let me know if I am not very clear
> > with what I am proposing or if you forsee problems with this logic.
> > if (dvd instanceof StringDataValue)
> >               dvd = dvd.getValue(dvf.getCharacterCollator(type));
>
> My comment isn't really the logic, I think we are just not talking about
> the same area.  I think the code above belongs hidden behind the new
> interfaces in the implementation logic of the data factory and data
> types, not an example of what callers of the datatype should be doing.
> >
> > Also, in the following line below
> > "I'll look at building/using DataFactory interface.  It will be some"
> > you mean DataValueFactory interface, right?
> >
> > Mamta
>
> Yes I meant DataValueFactory interface.  Let's work together on getting
> the DataValueFactory interface right.
>
> So far I have uncovered to basic ways store creates "empty" objects.
> Note that store really only needs "empty" objects, ie. it is going
> to initialize the state of these objects from disk by calling each
> objects readExternal() method.  But we have decided to not store
> the collation info as state in the object so somehow we need to get
> that info into the empty objects.
>
> The ways store currently creates these objects:
>
> 1) using Monitor to get dvd directly:
>    dvd = Monitor.newInstanceFromIdentifier(format id)
>
>    o I think this use is best implemented as Mamta suggests, just
>      providing a non-static interface on the DataValueFactory.
>      something like:
>
>      DataValueFactory dvf = somehow cache and pass this around store;
>      dvd = dvf.newInstance(format id, collation id);
>
>      at this point dvd can be used to correctly compare against other
>      dvd's in possible collate specific ways.
>
> 2) using existing dvd's class to get a new "empty" dvd that matches it
>    (which is why it does not call clone).
>    dvd = dvd.getClass().newInstance()
>
>    o less sure about this one.  Seems like we need a new dvd interface
>      that does the equivalent thing.  I believe the original code got
>      here because the original store code did not deal with DVD's it
>      just got objects, so could not make dvd calls.  There is a
>      getNewNull() interface, anyone know if there is any runtime work
>      that would be saved over this by creating a
>      getNewEmpty() interface?
>
>     dvd = dvd.getNewEmpty();
>
>     at this point dvd can be used to correctly compare against other
>      dvd's in possible collate specific ways.
>
> 3) optimized allocation, caching some of the work.  This is used
>    where one query may generate large number of rows - for instance
>    hash table scan and sorter calls.  Here the idea is to do some
>    part of the work once leaving an InstanceGetter which then can
>    repeatedly give back new objects in the most optimized way:
>
>    called once:
>    InstanceGetter = Monitor.classFromIdentifier(format id)
>
>    called many times:
>    dvd = InstanceGetter.getNewInstance()
>
>    o something like the following would be the direct conversion.  Note
>      that implementation of the Instance getter is probably more complex
>      now.  It can't just remember a single class and call new instance
>      on it.  It has to cache some info on what class to create and what
>      collation to set in it.
>
>    called once
>    DataValueFactory dvf = somehow cache and pass this around store;
>    InstanceGetter =
>          dvf.instanceGetterFromIdentifiers(format id, collation id)
>
>    called many times:
>    dvd = InstanceGetter.getNewInstance()
>
> again at this point dvd can be used to correctly compare against other
>      dvd's in possible collate specific ways.
>
>
>
> All 3 of these uses have to be replaced to allow store to create
> "correct" types which can be used in possible string comparisons.
>
>
>
>

Mime
View raw message