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 Mon, 07 May 2007 07:54:15 GMT

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

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


change 535770:
This checkin fixes create index, alter table, and bulk insert to correctly
set the collation in the persistent tables and indexes that they create.


> 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