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 Tue, 10 Apr 2007 17:59:32 GMT

     [ 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.


Mime
View raw message