You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mike Matrigali (JIRA)" <ji...@apache.org> on 2007/05/29 19:26:16 UTC
[jira] Resolved: (DERBY-2537) implement pushing collation info to
store, storing collation info in store metadata, and creating templates
based on store metadata
[ https://issues.apache.org/jira/browse/DERBY-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali resolved DERBY-2537.
-----------------------------------
Resolution: Fixed
> 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
> Assignee: 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.