TYPO3 Core

We'll discuss this.

Well, I just played a little bit with that.
Here's a patch that seems to work perfect (didn't have any problems yet) with prefixed tables.

What you need to do is this:
1) Create the database and admin user just as usual (doesn't work with prefix - yet)
2) When done, rename all tables within your database (you can do this manually or with the help of the attached script "rename_tables.sh")
3) Apply the patch to t3lib/class.t3lib_db.php
4) Adjust the table prefix on line 142.

It's nice to see how easy this works BUT I still see no reason for me to use such a feature.

I will not work on this any longer, please enhance it on your own and submit patches if you think they're good.

Cheers, michael

Thanks. I'm gonna try this.
I'll get back to you when I have something.

Very nice!

A possible problem that comes to my mind is the install tool when you click "COMPARE" in the "database analyzer" it suggests to rename all tables with the zzz_deleted_ prefix that are not needed by TYPO3.
I think that feature would have to be reviewed if such a patch makes it into 3.8, so for example it should not care about tables that have a different prefix than the one configured in t3lib_db.

Hi,

I've been fiddeling with an alternative way of doing this. The patch provided by stucki has the disadvantage that if you share the typo3 files between installations on the same server they are all stuck with the same prefix. This is because the prefix is set in the class.t3lib_db.php file which is shared between installations.

So I tried a slightly different approach (attached) based on the patch provided by Stucki. I regretably have to admit that I haven't had enough time to actually get this to work. So this patch doesn't work as it is now.
I'm still uploading it as a base for ideas for you guys.

This tar.gz file also includes a draft readme on how the installation procedure works in this alternate way.

An alternative method of doing this is what drupal ( http://drupal.org ) has done. They have all queries like this: " select foo from {bar} where ...." . Everywhere where a "{XXX}" appears they automagically replace that with "tableprefix_XXX" before executing the queries. Because the table dumps and upgrade scripts use the same system all scripts are "table prefix safe".

Niels Basjes

I don't know if extensions are developed with such a prefix in mind, at least I have never seen such a prefix in a DB query of an extension. Could this be an issue?

The problem with those "buggy" extensions is that they do not yet all use the database abstraction functions from $GLOBALS['TYPO3_DB'].

Of course this is an absolute requirement to have this working.

Perhaps DBAL could be used for such a prefixing?

Yes, and in the backend there needed to be a select box to switch among the TYPO3 installations with different prefixes. Or do they want to switch only some tables?

Franz, you cannot have BE-switch for this. This can only be a config option in localconf.php. Once in the BE you must already know to what DB or what DB/prefix-pair you are talking to.

With this setting you have a different BE for each prefix just as you would have with different DBs.

I've set this to "woun't fix". I don't think we want such an architecture change and databases aren't that expensive anymore.