This is mainly for @TE...
I'm looking into moving some {db_prefix}members columns into {db_prefix}members.data, where they'll be serialized and stored with other variables.
A few reasons for that...
- Well, there are 60 or 70 columns in that table... Not exactly EASY to browser through.
- I think I could save about a dozen (or at least half a dozen) columns by moving them to data.
- Basically, anything that (1) doesn't have an associated index, (2) doesn't need to be updated for anyone but the current user.
For now, I've moved 'mod_prefs' to data['modset'], and 'secret_question/secret_answer' to an array called secret_qa.
What I've been doing is: enter this into my new Upgrade script (not yet committed), where Wedge will get the existing entries, then convert them to data variables, and then remove the columns when it's done.
I guess it works fine if you're on a current install of Wedge: the upgrade script will pick it up, and then upgrade your table automatically.
But what if you're installing a new version..? The upgrade script won't run, because the database is in the new format, and it doesn't need to run. So... What to do?
(a) Leave the database with all these extra fields, because it's only annoying when browsing through phpMyAdmin, but 10 less fields won't make a big difference in either convenience or performance. (I'm not saying it won't; I'm giving you an opportunity to say whether you think it will.)
(b) Leave the database as is, at Wedge install time. Also set the database version to zero, basically... And let Wedge process it. But this means the import process needs to be done immediately after installing. Ouch... (Because, otherwise, Wedge will then start the upgrade process, and then delete the columns after it's gotten zero results on secret_* etc.)
(c) Add some code in the import script to make it possible to easily import an member field into the members.data field.
What do you think, guys..? (Especially Thorsten!)
I'm looking into moving some {db_prefix}members columns into {db_prefix}members.data, where they'll be serialized and stored with other variables.
A few reasons for that...
- Well, there are 60 or 70 columns in that table... Not exactly EASY to browser through.
- I think I could save about a dozen (or at least half a dozen) columns by moving them to data.
- Basically, anything that (1) doesn't have an associated index, (2) doesn't need to be updated for anyone but the current user.
For now, I've moved 'mod_prefs' to data['modset'], and 'secret_question/secret_answer' to an array called secret_qa.
What I've been doing is: enter this into my new Upgrade script (not yet committed), where Wedge will get the existing entries, then convert them to data variables, and then remove the columns when it's done.
I guess it works fine if you're on a current install of Wedge: the upgrade script will pick it up, and then upgrade your table automatically.
But what if you're installing a new version..? The upgrade script won't run, because the database is in the new format, and it doesn't need to run. So... What to do?
(a) Leave the database with all these extra fields, because it's only annoying when browsing through phpMyAdmin, but 10 less fields won't make a big difference in either convenience or performance. (I'm not saying it won't; I'm giving you an opportunity to say whether you think it will.)
(b) Leave the database as is, at Wedge install time. Also set the database version to zero, basically... And let Wedge process it. But this means the import process needs to be done immediately after installing. Ouch... (Because, otherwise, Wedge will then start the upgrade process, and then delete the columns after it's gotten zero results on secret_* etc.)
(c) Add some code in the import script to make it possible to easily import an member field into the members.data field.
What do you think, guys..? (Especially Thorsten!)