not a block - but still a req: Table prefix
Permalink
Hi
to give users with only 1 database the ability to install c5 I am whishing for a table prefix!
Please change the code, so that the user can not only choose a database, but also a table prefix which will enable him to install in a database together with other software.
I strongly believe, this should not be a big problem and be standard procedure: So many applications offering this as the number of databases is still very often limited.
Olaf
to give users with only 1 database the ability to install c5 I am whishing for a table prefix!
Please change the code, so that the user can not only choose a database, but also a table prefix which will enable him to install in a database together with other software.
I strongly believe, this should not be a big problem and be standard procedure: So many applications offering this as the number of databases is still very often limited.
Olaf
Hi Franz,
>I think this is a really dangerous idea
>for a very small benefit.
Dangerous? I do not see why this is more dangerous than the way it is handled right now. Maybe even the opposite: Right now everyone knows all my table names. The prefix might protect a litte. (But well, we both know, that this "protection" is not enough.)
>Using table
>prefixes really is only going to work if
>not a lot is going on in that database and
>no tables get made that might conflict.
Why? It's still a name and besides, that the application needs to read/write/send a couple of characters more (example: c5_), I can not come up with any reason why this should be slower and slow database access.
>Since c5 is a very extendable cms, its
>quite likely a block developer will want
>to make a table of this name or that - so
>we can't really say "Every C5 site will
>have the same set of tables"...
Well, that's why the prefix should be saved for example in the site.php file, together with the other database data. Other applications do not have any problems, and right now it seems (no offense meant here) you are creating some problem - that is not there.
Storing the prefix for example in site.php all extension builders can grab that constant and attach their table name as a suffix (like: c5_myTable).
The problem with same names for different add-ons is always there when we are working on Open Source Software. Imagine for example Moodle. Moodle is an E-learning software with hundreds of extensions. Or imagine phpBB which has alot of mods as well. Of course a developer of an extension needs to make sure that his tables do not interfere (overwrite) tables of the core of the application. But there is no way the maintainers (you guys right now) of the "main"-program can control programming so much that there is not a chance for problems.
A developer will most likely create something and name the tables similar to his - lets say extension. Well, so there is an extension named "My_great_Chat" - the tables might be names "my_great_chat_something". Put a prefix (c5_) there and get a nice named table.
I know, that this (usage of a prefix) means of course the C5 code needs adjustments, but I would think this should be able to be done relatively easy (search & replace might actually work).
>I see this as a great way to have a non->working c5 site,
I hope I was able to give a hint why I do not see any problems (concerning extensions and future development) ...
>and perhaps break some other stuff that
>already worked on your website before.
... and this is something nobody can be sure of to avoid when updating. Of course there can be conflicts with extensions / user made changes (that happens with open source products) when a new release is thrown over an old one. This can not always be avoided and also can not always be avoided when you release a new version. There might be problems when upgrading. For extensions that do not work anymore - well - that's open source and it's good this way because people can go ahead and patch a file / extension to work again.
Even though I am not sure if I was able to make myself clear in the last paragraph, I hope the over-all reasoning is understandable.
After my experiences with TSEP (http://tsep.info ) I have to say: The work of adding table prefix (in the early state of programming = in the early state of open source) is worth it.
>We'll gladly host your c5 site for $15/
Well, I do not have a problem, but there are a lot of providers, charging extra for extra DBs.
I was just thinking of the possility that C5 might loose to another CMS.
Olaf
>I think this is a really dangerous idea
>for a very small benefit.
Dangerous? I do not see why this is more dangerous than the way it is handled right now. Maybe even the opposite: Right now everyone knows all my table names. The prefix might protect a litte. (But well, we both know, that this "protection" is not enough.)
>Using table
>prefixes really is only going to work if
>not a lot is going on in that database and
>no tables get made that might conflict.
Why? It's still a name and besides, that the application needs to read/write/send a couple of characters more (example: c5_), I can not come up with any reason why this should be slower and slow database access.
>Since c5 is a very extendable cms, its
>quite likely a block developer will want
>to make a table of this name or that - so
>we can't really say "Every C5 site will
>have the same set of tables"...
Well, that's why the prefix should be saved for example in the site.php file, together with the other database data. Other applications do not have any problems, and right now it seems (no offense meant here) you are creating some problem - that is not there.
Storing the prefix for example in site.php all extension builders can grab that constant and attach their table name as a suffix (like: c5_myTable).
The problem with same names for different add-ons is always there when we are working on Open Source Software. Imagine for example Moodle. Moodle is an E-learning software with hundreds of extensions. Or imagine phpBB which has alot of mods as well. Of course a developer of an extension needs to make sure that his tables do not interfere (overwrite) tables of the core of the application. But there is no way the maintainers (you guys right now) of the "main"-program can control programming so much that there is not a chance for problems.
A developer will most likely create something and name the tables similar to his - lets say extension. Well, so there is an extension named "My_great_Chat" - the tables might be names "my_great_chat_something". Put a prefix (c5_) there and get a nice named table.
I know, that this (usage of a prefix) means of course the C5 code needs adjustments, but I would think this should be able to be done relatively easy (search & replace might actually work).
>I see this as a great way to have a non->working c5 site,
I hope I was able to give a hint why I do not see any problems (concerning extensions and future development) ...
>and perhaps break some other stuff that
>already worked on your website before.
... and this is something nobody can be sure of to avoid when updating. Of course there can be conflicts with extensions / user made changes (that happens with open source products) when a new release is thrown over an old one. This can not always be avoided and also can not always be avoided when you release a new version. There might be problems when upgrading. For extensions that do not work anymore - well - that's open source and it's good this way because people can go ahead and patch a file / extension to work again.
Even though I am not sure if I was able to make myself clear in the last paragraph, I hope the over-all reasoning is understandable.
After my experiences with TSEP (http://tsep.info ) I have to say: The work of adding table prefix (in the early state of programming = in the early state of open source) is worth it.
>We'll gladly host your c5 site for $15/
Well, I do not have a problem, but there are a lot of providers, charging extra for extra DBs.
I was just thinking of the possility that C5 might loose to another CMS.
Olaf
Don't get me wrong, I can see you're very passionate about this, and I'm eager to hear what everyone thinks on it.
Personally, I just think one app = one database is a very simple and standard way to setup a safe server environment. I'm still concerned that this represents real (not huge, but when thinking about upgrade issues, very real) work and the only benefit I see is encouraging sloppy database management.
My concerns about speed aren't the table names, its the "what else is going on with this database" questions.
Anyone else have an opinion on this? Maybe I'm missing something.
Personally, I just think one app = one database is a very simple and standard way to setup a safe server environment. I'm still concerned that this represents real (not huge, but when thinking about upgrade issues, very real) work and the only benefit I see is encouraging sloppy database management.
My concerns about speed aren't the table names, its the "what else is going on with this database" questions.
Anyone else have an opinion on this? Maybe I'm missing something.
Hi Franz,
at university I once had a professor who said he can fight - scientifically - with his colleague and afterwards go and have a beer and celebrate with the same person.
No, I am not offended! I see this as the same scientific disagreement: We talk, present opinions and our points of view and both hope to get to a better solution.
Well, back to our topic. By now I have seen, that someone else requestes this feature (http://www.concrete5.org/community/features/database_table_prefix_during_install) already (I was one of the people voting for very important).
>Personally, I just think one app = one
>database is a very simple and standard way
>to setup a safe server environment.
I agree, this is of course something to consider. But there are so many possible options where mistakes can lead to unsecure database access / server /xss etc.
Maybe it's because C5 was built for companies who are willing to buy more webspace etc. But I think in the open source, C5 will be interesting for many more people who might not be willing to pay more for hosting just because they need a new database - there people might just skip right ahead of C5 to a different CMS.
About security: Maybe suggest, that the site.php file is not reachable from the web because it's not in / below the website root but outside. (I usually create a file that is outside the webroot with all the database data and include this for the application).
Also suggesting to the user, to secure the config directory using .htaccess, might improve security.
>I'm still concerned that this represents
>real (not huge, but when thinking about
>upgrade issues, very real) work
Well, once - but not more than that - am I wrong here?
>and the only benefit I see is encouraging
>sloppy database management.
This I do not understand. If developers create tables with or without a prefix - where is the difference for developers?
Besides that: So many databases in online environments do not care about cascading deletes and updates, nor about referential integrity. This is something I would call sloppy DB design - not how a developers names his tables.
>My concerns about speed aren't the table
>names, its the "what else is going on with
>this database" questions.
Ah, I did not get this before. Nevertheless: Do you think there is a difference if there are 2 programms accessing the same database compared to 2 programms accessing different databases? It's still Mysql and (most likely) on the same hardware. I agree, that there _might_ be a difference but for (I know, I am leaning far out of my window now) most users I would not see a problem here. If there are so many database queries send, if there are so many hits on a website that this would (severely) impact performance
a) the company can always set up a new database for the application (1 DB for 1 application as you suggested) or
b) try using different "tricks" (caching, static / precomipled files etc.)
>Anyone else have an opinion on this?
I am curious too - let's hear it ;-)
Olaf
at university I once had a professor who said he can fight - scientifically - with his colleague and afterwards go and have a beer and celebrate with the same person.
No, I am not offended! I see this as the same scientific disagreement: We talk, present opinions and our points of view and both hope to get to a better solution.
Well, back to our topic. By now I have seen, that someone else requestes this feature (http://www.concrete5.org/community/features/database_table_prefix_during_install) already (I was one of the people voting for very important).
>Personally, I just think one app = one
>database is a very simple and standard way
>to setup a safe server environment.
I agree, this is of course something to consider. But there are so many possible options where mistakes can lead to unsecure database access / server /xss etc.
Maybe it's because C5 was built for companies who are willing to buy more webspace etc. But I think in the open source, C5 will be interesting for many more people who might not be willing to pay more for hosting just because they need a new database - there people might just skip right ahead of C5 to a different CMS.
About security: Maybe suggest, that the site.php file is not reachable from the web because it's not in / below the website root but outside. (I usually create a file that is outside the webroot with all the database data and include this for the application).
Also suggesting to the user, to secure the config directory using .htaccess, might improve security.
>I'm still concerned that this represents
>real (not huge, but when thinking about
>upgrade issues, very real) work
Well, once - but not more than that - am I wrong here?
>and the only benefit I see is encouraging
>sloppy database management.
This I do not understand. If developers create tables with or without a prefix - where is the difference for developers?
Besides that: So many databases in online environments do not care about cascading deletes and updates, nor about referential integrity. This is something I would call sloppy DB design - not how a developers names his tables.
>My concerns about speed aren't the table
>names, its the "what else is going on with
>this database" questions.
Ah, I did not get this before. Nevertheless: Do you think there is a difference if there are 2 programms accessing the same database compared to 2 programms accessing different databases? It's still Mysql and (most likely) on the same hardware. I agree, that there _might_ be a difference but for (I know, I am leaning far out of my window now) most users I would not see a problem here. If there are so many database queries send, if there are so many hits on a website that this would (severely) impact performance
a) the company can always set up a new database for the application (1 DB for 1 application as you suggested) or
b) try using different "tricks" (caching, static / precomipled files etc.)
>Anyone else have an opinion on this?
I am curious too - let's hear it ;-)
Olaf
I will hold it short:
table prefixes are a must have simply to avoid problems with other scripts using the same table names.
Please keep in mind that in Europe most webhosters deliver only one database for some fair monthly bugs.
D.
table prefixes are a must have simply to avoid problems with other scripts using the same table names.
Please keep in mind that in Europe most webhosters deliver only one database for some fair monthly bugs.
D.
Hi D.
thanks for stressing this:
>table prefixes are a must have simply to
>avoid problems with other scripts using
>the same table names.
Agreed.
Olaf
thanks for stressing this:
>table prefixes are a must have simply to
>avoid problems with other scripts using
>the same table names.
Agreed.
Olaf
I tend to agree one DB per app. mainly because just with c5 alone your looking at 60 tables. now add a wordpress install using the same DB and your looking at another 10 to 70 tables added on to the first 60. so now think of the possibility of said DB/tables getting corrupt and your site as a whole dies. where as if you have a db for each then if one dies your whole site doesn't.
not sure if that makes sense, but was just thinking. :)
not sure if that makes sense, but was just thinking. :)
Hi
I agree with the many tables point, but because of the prefix it's still easy do differentiate between them.
But - the point of backups - well .... counts somehow. In my opinion wrecking one database which your webspace is based on would pretty often wreck the whole setup. Thus meaning it's up to the admin/user to create backups of data: FTP as well as database. If this can be automated - great - if it can't it's up the the admin.
Following this string of thought it does not matter if everything is in one database or if several databases are used.
Some other point: Maybe different domains use the same backend - and the same databases. For examle if you have 2 databases, the admin might want to use one database for one domain - and the other for the other domain.
This calls for table prefixes.
Olaf
I agree with the many tables point, but because of the prefix it's still easy do differentiate between them.
But - the point of backups - well .... counts somehow. In my opinion wrecking one database which your webspace is based on would pretty often wreck the whole setup. Thus meaning it's up to the admin/user to create backups of data: FTP as well as database. If this can be automated - great - if it can't it's up the the admin.
Following this string of thought it does not matter if everything is in one database or if several databases are used.
Some other point: Maybe different domains use the same backend - and the same databases. For examle if you have 2 databases, the admin might want to use one database for one domain - and the other for the other domain.
This calls for table prefixes.
Olaf
If not a prefix option in order to avoid name collisions, I at least think it could be beneficial to be able to install C5 to a database with existing tables.. I've had to previously modify the install code in order to skip the table checks to do this (dangerous yes I know). Some end users might already have an existing web application that they are/will convert to C5 and wish to do so without having to export->drop->import their existing table data.
Why have the warning/error "There are already X ammount of tables in the target database" ?
Why have the warning/error "There are already X ammount of tables in the target database" ?
Trying to help someone who might stupidly key in the wrong database and obliterate an existing site. Pretty low risk, but potentially catastrophic.
I could see flashing that warning once, and giving an "I'm sure I want to install here" checkbox to specify that that is the database desired to be used (and those tables overwritten).
I could see flashing that warning once, and giving an "I'm sure I want to install here" checkbox to specify that that is the database desired to be used (and those tables overwritten).
Because of prefix lack I was not able to use Conrete before. My webhotel is giving one database and I have not possibility to create separate database for Concrete.
I see this as a great way to have a non-working c5 site, and perhaps break some other stuff that already worked on your website before.
We'll gladly host your c5 site for $15/momth and give you as many MySQL databases as you want for that. I think there are many other web hosts would offer just as good of deal as well.