Upgrade strategy D5 -> D6 ?

I havent thought about it. Unfortunately i dont think i will have time to think about it.

You've made fundamental changes to mail_edit 6.x-1.x and I don't think that upgrading can be automated in a meaningful way.

A major problem is that we don't know what people have done with ME5 and what modules have been using it.

Subscriptions has used it heavily, and I have adapted Subs6 to the new ME6, retaining the template strings in the process. Knowing that, and with the intimate knowledge of how the D5 pieces fit into the D6 versions, I'm contemplating to implement an upgrade routine for Subscriptions' templates. I think I could migrate pretty much everything, as far as Subscriptions is concerned, but I wouldn't know what to do with other templates (if any).

If you're willing to accept a patch for ME6 that migrates the Subscriptions templates and drops any others, then I'd work on this. Alternatively, if your approach is to have people uninstall ME5 (losing all templates) and begin from scratch with ME6, then I could write a subscriptions_update_N() function that destroys the D5 {mail_edit} table and creates a D6 {mail_edit} table with the Subscriptions templates.

Which way should I go?

I am against anything that destroys data. i will only accept upgrade path patches that migrate data safely.

Having said that, hook_upgrade_n() could implement multiple upgrade paths in a single function deppending on conditional statements of module_exists which checks if mail_edit exists. same goes for mail_edit with regards to subs. the trick is to figure out which module does what ? i wouldnt want either module to creep it's scope onto another, but sometimes that is inevitable.

Well, the trouble is that the D5 {mail_edit} table has these fields

description
subject
body
mailkey

and the D6 {mail_edit} table has

description
subject
id
language
body

The D5.mailkey is an arbitrary string created by the client module, e.g. 'subscriptions-node-type-forum', while the D6.id is something like 'subscriptions_content_node-type-forum'. In D5, all of the mailkey was supplied by the module, so it's completely arbitrary, while in D6 you prepend the name of the module ('subscriptions_content' here) to the string that's supplied by the module.

Your D6 version has an additional table {mail_edit_registry} with

id
module
mailkey
description

I don't see how to populate all the fields. Moreover, your D6 version requires significantly more cooperation (a bunch of new hooks) from client modules than did the D5 version, so even if we can somehow move the data over to D6, client modules need to be adapted to work with the new mail_edit.

Let's take a step back: Right now you have no upgrade path at all, and trying to install the D6 version on a database that was upgraded from D5 will simply fail.

How about just renaming the old {mail_edit} table to {mail_edit_D5} and start from scratch with new empty tables? This would let any cooperating modules pick up their pieces, if they want.

This sounds like a mere hack and not an ugprade path.

It preserves all data, as you requested, and under that requirement it's the best we can do without intimate (and clairvoyant!) knowledge of each and every module that has contributed a record into the D5 {mail_edit} table.

I happen to know that I need to turn 'subscriptions-node-type-forum' into 'subscriptions_content_node-type-forum', because I've implemented it. The new 'content' part is not my choice, but it was forced upon me by a relation that you impose between the IDs and the hook functions (depending on where the hook function resides). If you wanted to write a hook_update_N(), you couldn't possibly know that, so without me having ported and adapted Subscriptions, you'd have no way of doing the right thing. This holds for every client module.

I havent really imposed anyhting. if you check how d6 mail keys are generated you will see that it is a concatination of module name + mail name string (which can still be arbitrary).

Let's not get side-tracked. I used that only as an example of how various factors including internals of mail_edit and the client modules can influence how the data of each client module needs to be transformed when going from D5 to D6. There is no algorithm that will do that generically, i.e. no hope of providing a mail_edit_update_N() function that can do it, because it will be different for every client module.

The logical consequence is that the best we can do is to rename the old {mail_edit} table to {mail_edit_D5} and start from scratch with new empty tables.

Starting with new tables is a necessity for installing the D6 Mail Editor, and since we don't know how to migrate the data, they'll be necessarily empty. Do you see an alternative?

Let's move forward. You put yourself where you are now by willingly burning the bridges. I'm not saying this is bad, in fact the new mail_edit is very nice, but you haven't thought about migrating the data and it's too late know. This must not stop us from providing a way for D5 users to install the D6 version without having to muck with the database and deleting their old {mail_edit} table manually.

will a patch follow?

Yes, if we agree on the strategy — do we?

Since i intend to put very little time into implementing any of the discussed, i feel it is not just for me to force any particular direction. If you feel that you approach is good long term then i encourage you to implement it.

and i do appreciate you putting time into this. thank you.

Ok, thanks.

BTW, as discussed in #136078: New module update numbering scheme for contrib modules, structured numbering doesn't work for the hook_update_N() functions in contrib, so I'll provide a low-numbered one. Let me know if you prefer a structured number.

Up to you. I am not really familiar with that issue so seeing you implement it will be a good educational piece for me.

I'm upgrading to 6 now. Can I just drop the mail_edit table as suggested earlier in this thread?

I've only installed Mail_Edit because of the dependency of Subscription and I've never created any "custom" templates - so I'm thinking that dropping that mail_edit table and enabling the new D6 supported MailEdit will be smooth, yes?

Yes, that would work, but then we'd lose a valuable test case. I'm sorry I haven't been able to get to this yet.

It would be extremely helpful if you'd be willing to do some testing with this when I have it ready. If yes, then please only rename {mail_edit} to {mail_edit_D5} rather than dropping it (and keep {subscriptions_mail_edit}!).

This will give you full functionality now and keep the door open for a test run.

Will do! Let me know me know more when you would like for me to test.

Ok, here's the patch as discussed above.

In addition to renaming the D5 mail_edit table to mail_edit_d5 (to make room for the new incompatible D6 mail_edit table) I've made the following changes:

1. Fix the schema and include the schema fix in the update_6000() function.

2. Turn the admin/build/mail-edit page into a form so that it can be hook_form_alter()ed. I need this to display something like the attached screenshot from Subscriptions, and any other module that wants to import its old D5 templates into the D6 installation can do the same.

P.S. I'll post the Subscriptions update after this is committed.

@cozzi: If you have a test site, please put the new {mail_edit} and {mail_edit_registry} tables out of the way and rename {mail_edit_d5} back to {mail_edit}.
Running the update in this patch should rename the old {mail_edit} to {mail_edit_d5} (as you did manually) and create fresh {mail_edit} and {mail_edit_registry} tables.
Don't do this on a production site, because the new tables will be empty, i.e. you'll lose your customizations.

Here's a revised patch that avoids calling
hook_schema() from hook_update_6000() and
hook_update_6000() from hook_install()
at the cost of duplicating the schema, according to http://drupal.org/node/150220 .

bump

committed to d6-dev.

now the question is: does this single commit warrant an official d6 release.

@cozzi: Would you try this now?

Update Subscriptions to BETA5, rename the {mail_edit} and {mail_edit_registry} tables with your current data (for safe-keeping), and rename the old saved {mail_edit_D5} back to {mail_edit}. Then visit admin/build/mail-edit — it should offer to import the old templates. Do this and verify that your customizations come up.

Thanks in advance!

Automatically closed -- issue fixed for two weeks with no activity.