[
https://issues.apache.org/jira/browse/JAMES-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier updated JAMES-3631:
----------------------------------
Description:
h2. Context?
The count of Cassandra table impact overall performance.
For people collocating several James cluster on distinct Cassandra keyspace
their counts can quickly add up.
Thus sanitizing schema transitions, in addition to clean code up also enable to
keep table count low.
h2. Why?
In 2018 we migrated the way to structure MailRepository, and supplied a
fallback mechanism, without providing means to migrate them from the old schema
to the new.
An easy mean is to rely on reprocessing:
- In mailetcontainer.xml define an orphan processor with just a ToRepository
mailet for the processor you wishes to migrate.
- Then trigger a full reprocessing.
- Emails will be re-added but in v2
Doing the upgrade with empty mail repository works too.
People adopting distributed James after version 3.4.0 are not impacted.
h2. What to do from there?
- Document commands to audit if a migration is needed
- Document the migration process (prior to an upgrade)
- Document that after the upgrade the table can be dropped.
- Drop the table off James code.
was:
h2. Context?
The count of Cassandra table impact overall performance.
For people collocating several James cluster on distinct Cassandra keyspace
their counts can quickly add up.
Thus sanitizing schema transitions, in addition to clean code up also enable to
keep table count low.
h2 Why?
In 2018 we migrated the way to structure MailRepository, and supplied a
fallback mechanism, without providing means to migrate them from the old schema
to the new.
An easy mean is to rely on reprocessing:
- In mailetcontainer.xml define an orphan processor with just a ToRepository
mailet for the processor you wishes to migrate.
- Then trigger a full reprocessing.
- Emails will be re-added but in v2
Doing the upgrade with empty mail repository works too.
People adopting distributed James after version 3.4.0 are not impacted.
h2. What to do from there?
- Document commands to audit if a migration is needed
- Document the migration process (prior to an upgrade)
- Document that after the upgrade the table can be dropped.
- Drop the table off James code.
> Migration strategy for Cassandra mailRepository
> -----------------------------------------------
>
> Key: JAMES-3631
> URL: https://issues.apache.org/jira/browse/JAMES-3631
> Project: James Server
> Issue Type: Improvement
> Components: cassandra, MailStore & MailRepository
> Affects Versions: master
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.7.0
>
>
> h2. Context?
> The count of Cassandra table impact overall performance.
> For people collocating several James cluster on distinct Cassandra keyspace
> their counts can quickly add up.
> Thus sanitizing schema transitions, in addition to clean code up also enable
> to keep table count low.
> h2. Why?
> In 2018 we migrated the way to structure MailRepository, and supplied a
> fallback mechanism, without providing means to migrate them from the old
> schema to the new.
> An easy mean is to rely on reprocessing:
> - In mailetcontainer.xml define an orphan processor with just a ToRepository
> mailet for the processor you wishes to migrate.
> - Then trigger a full reprocessing.
> - Emails will be re-added but in v2
> Doing the upgrade with empty mail repository works too.
> People adopting distributed James after version 3.4.0 are not impacted.
> h2. What to do from there?
> - Document commands to audit if a migration is needed
> - Document the migration process (prior to an upgrade)
> - Document that after the upgrade the table can be dropped.
> - Drop the table off James code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
