db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2537) implement pushing collation info to store, storing collation info in store metadata, and creating templates based on store metadata
Date Thu, 19 Apr 2007 23:19:15 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Matrigali updated DERBY-2537:
----------------------------------

    Attachment: derby-2537_3.diff

derby-2537_3.diff  is not ready for checkin. The main goal of this checkin is to finish the
work of creating
"correct" dvd templates in the store, using the store's collation metadata and the new interface
that takes
a format id and collation id and gives back an template object which can be initialized by
store with a 
readExternal.  The bulk of the changes are work to get the DataValueFactory into places where
before we
called a static monitor routine.   It passed all tests before being integrated with the latest
change
to return DVD's from DataValueFactory.getNull().  After integration it failed as store needs

DataValueFactory.getNull() to support returning classes for RowLocations.  The specific implementation
of Rowlocations is currently hidden from the data factory, but they are known to implement
DVD.  

I am not sure what the right way to implement this is.  In this patch I added support for
the heap row location
format id by calling the Monitor to get it  from the format id.  If this is not ok, does anyone
have an alternate
suggestion?

I am rerunning all the tests to see if there is any other problems.  If all the tests pass
and I don't hear otherwise I will check this in, and if later a better suggestion on the rowlocation
support comes I will be
happy to change it.

> implement pushing collation info to store, storing collation info in store metadata,
and creating templates based on store metadata
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2537
>                 URL: https://issues.apache.org/jira/browse/DERBY-2537
>             Project: Derby
>          Issue Type: Sub-task
>          Components: SQL, Store
>            Reporter: Mike Matrigali
>         Assigned To: Mike Matrigali
>             Fix For: 10.3.0.0
>
>         Attachments: derby-2537_3.diff, derby2537_1.diff, derby2537_2.diff
>
>
> Implement subtasks associated with pushing and using collation info in store.
> As was discussed on list the aproach will be:
> o store collation info gets passed into createConglomerate() using an enhanced version
of the exising CollumnOrdering interface
> o store collation info will also have to get passed into interface that adds a column
to a heap
> o collation info will be added to the store metadata so that correct collation datatypes
can be created internal to store where there
>     may no access to system catalogs (for instance at  database recovery time).   A new
heap and btree metadata version will be
>     added which will included a "sparse" on disk format which will describe those columns
that have a collation id that is different
>     than the default.  
> o soft upgrade will be handled by insuring old format is readable by existing code and
automatically creates current version of in memory structures by
>     assuming all old format conglomerates have default collation info.  Soft upgrade
will never create new format heap or btree metadata.
> o hard upgrade will  write new format conglomerate metadata for conglomerates created
after the upgrade, no work  will be done at upgrade time.  
>     Note the  proposed implementation of collation feature in 10.3 will only allow new
dbs to set alternate collation, so in 10.3 hard upgrade is not 
>     actually necessary but  provides a consistent approach to internal store structures.
 It also will allow  for a future where more collation control
>     is allowed in dbs.
> o store needs to create templates sometimes, to do this with correct collation info some
of the Monitor functionality to create templates will be
>     moved from monitor into datatype factory and enhanced to take collaiton id info where
it currently only takes format ids.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message