Print

[ecto]

...and not just "cpg_" instead? Why have version number in the table prefix? Then when you update CM the table prefix says another version than it really is, if it isn't changed.. just seems unlogical to me. Something for future features, where one has to tell old and new tables apart easily?

[Abbas Ali]

The table prefix is absolutely changeable and you can do so at the time of installation.

There is nothing illogical in that prefix. I would rather say that it is very logical to keep it like that. There is a huge reason to keep it like that. Many people host their sites on shared webservers where they get only one database. If they want two versions of cpg installed, then the table names would conflict if prefix for both is kept "cpg_".

As far as upgradation is concerned, one can always change the table prefix if he knows his way around in phpmyadmin or anyother database tool.

[Paver]

But shouldn't an upgrade change the table names during the upgrade?  That would make sense.  The upgrade SQL script already inserts tables and adds fields as necessary.  It needs to make sure all the tables it expects are there.  Shouldn't it rename the tables so that once the upgrade is complete, the new table names correspond to the Coppermine version using the tables?

Or is there a reason to have the table names reflect the version of Coppermine initially installed? (for people who don't specifically change the table prefix)

[Tranz]

It's not necessary to worry about what the prefix is and could even cause issues to change it for upgrades. A user could choose a prefix like 'pictures' -- thus, no indication of it being Coppermine or the version. It has no effect on functionality. The installation script's suggested addition of version number reduces the likelihood of colliding installations, as Abbas pointed out, but users don't have to abide by them.

And you can ask the same question of many other projects that append the version number to the suggested table prefix about why they do it.

[ecto]

Thanks for the answers. I know you can have the prefix say whatever you wish, I already changed mine. I thought like Paver, that a change of table prefix name during an upgrade would make sense, but the collision risk might be an issue then.

But.. about the collision risk. Even if users are on a shared webserver with one MySQL, they will (probably) still have separate Coppermine database names (which doesn't default to anything during install). And then table names won't be an issue, since they are in different databases anyway. So the only realistic risk situation is, as I understand it, if someone has two or more Coppermine installations using the same database. And why anyone would like to do that if they're not forced to (only allowed one database on a shared host for example) I don't understand, since it'll only make it harder to administer (dumps etc) several Coppermine installations in the same database.

Don't get me wrong, I'm not against the naming convention. Everything that minimizes potential risks are a good thing. Just thinking out loudly..

[Paver]

I'm thinking out loud as well...  Sure, people can easily change it.  What I'm suggesting is that people who don't customize the installation and just want to click install and then start adding photos wouldn't touch the default table name so why not check for the default table name during an upgrade and modify it to the new default table name?  If the user did customize it originally, don't touch it (even if the user customized it to coppermine131 since the user actively chose the table name and should be responsible to change it again if desired).

Yes, this is not a serious issue and I'm not trying to belabor the point unnecessarily.  What I have been doing is thinking about organizing things into something like basic and advanced for things like installation parameters & steps and admin settings and tools.  Along those lines, for people who never touch the table or database name, who never adjust the directory names or file prefixes, who never change the forbidden characters in filenames, etc. (because they have no reason to) - those people might be using Coppermine 2.1.1 with a table prefix of 1.3.2.  Sure it doesn't really matter, but it just seems to make sense that during an upgrade the newly upgraded Coppermine should look identical to a fresh installation of the new version (except for user settings which have been carried through).  A more serious instance of this lack of foresight is the "factory default" button in 1.4.2 which turns the password encryption on and causes a serious issue for people who upgraded from 1.3 and have all plain-text passwords.  I'm not at all saying this was an intentional lack of foresight.  What I'm suggesting is a general mindset for things like upgrades where the person now has a "real" version of 1.4.2 after upgrading with no legacy artifacts except for ones that are customization settings in 1.4.2 (like having plain-text passwords).  The table prefix is just one example that proves the point (if you agree) or is a consequence (if you disagree) of this general mindset.  Another instance of the utility of such a general mindset is in the language translations.  Another thread has a good discussion of this.

So that's what I'm thinking.  Please take it as constructive criticism and as being meant not as a nuisance but to encourage useful discussion.

[Joachim Müller]

renaming the table prefix during upgrades definitely is a bad idea and won't be added. I can see your points, but from my experience, this "issue" simply doesn't exist - we didn't have any support requests so far that related to this. Having coppermine version of the "original" install remain in the table prefix even if a user upgraded sometimes is helpful when supporting, so imo this should stay just as it is. I can see no valid reason to change the default prefix.

Regarding the passowrd encryption and "reset to default" button not working in the first place: this is definitely a bug, and it has been fixed. There will be a maintenance release soon. However, it's not related at all to the table prefix stuff. Please stick to one issue at a time.

Joachim

[Paver]

Ok, fair enough.  I do realize the table prefix is a minor issue (or a minor non-issue as the case may be), and I understand all the reasons mentioned to keep things as they are.  I also understand the reasons for keeping one issue per thread but thought an explanation on why I think the way I do about such a minor issue and why I was suggesting the upgrade change was warranted and it justified mentioning the bigger picture (from what I saw as the bigger picture).  As I said, I didn't mean to disparage anyone by bringing up the password bug.

Thanks for the comments.  I'm fairly new to the forums and still getting a feel for the development views & goals.