[jira] Updated: (DERBY-2537) implement pushing collation info to store, storing collation info in store metadata, and creating templates based on store metadata

["Mike Matrigali (JIRA)" <ji...@apache.org>]

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

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

    Attachment: derby2537_1.diff

derby2537_1.diff provides the initial framework for reading/writing the new collaiton metadata in store.  I ran all the tests and got a few errors that I am still looking at - I think these are not related to my changes but will resolve before committing the change.  This change is an incremental step, it just stores the default  collate info - more work is needed to get the new collate info down to store.

Note when this gets checked in you will get errors accessing any existing databases created off the trunk.  We don't handle upgrade within versions in the trunk.  Upgrade from 10.2 db's will be fully supported when released.

> 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: derby2537_1.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.