I've also asked this question to Bård. It seems that each site needs its own set of tables. And the Ez crew are not willing to prefix the tables for each site. It's about backup issues and messy coding, he argued. So sorry, I don't think you'll get that in the nearest future.
I think the solution to your problem (Which at least I think is relevant) is to include a site id in the database tables. This way eZ Publish could give you what you are asking for. Some might then complain about overhead in the systems, and that is a case. But it will only be a problem if more than one site is installed into one database. There are a lot of problems to be solved before this really would work out. For example the connection between the site design and the site id++.
So for now you must install every site into each own database.
Hm.
Makes no sense to me.
_I_ guess, that the package system just does not handle installing multiple packages in one DB, because it's difficult to handle the ID's and the referential integrity of the objects of the different objects. When the DB is empty and just one DB is installed, the IDs (primary keys) are much more predictable.
Can the creator of the package system please comment on this?
I don't believe, that there is a real reason for seperate DB's, because:
1. In ez 3.1, everything was installed in one db, without problems 2. How are shared Information, like Users, Groups, Roles handled, when the content information is spread over several DBs???
If I am not mistaken the difference between the earlier demosetup and the new packages in 3.2 is that the focus of the new packages are to provide sample sites that only use a smaller subset of the functionality. The previous demodata was more of an "all in one" package.
So the "solution" to this problem is rather to include a similar package in 3.2, with more functionality than just "one site"..
This is only what I figured out though, I might be wrong ..
The major reason for this is that the new package system cannot handle object export import yet, it only handles running an SQL file. With object import there should be less problems with having multiple packages in one database.
But even if we did have (when we get) this feature there will be problems.
- All demo templates cannot work with hardcoded node id's, either a new set of 'global' id's must be introduced or use ini configurations. - Conflict of data, for instance one package might have specific setup of roles and perhaps some ready to use users. Another package might have a totally different setup of roles which could easily be conflicting (not to mention objects, just think about the admin users).
All in all it means that the package system must analyze all the data of the different packages, find out what differs, what conflicts and either give the user the possibility to resolve the conflict or do some automagic.
From what I can tell, all of the tables except that for the corporate site have a full set of tables, so where's the "each site needs its own set of tables argument?
The need for multiple admin sites also makes me think that the developers have taken a turn down the "let's make it harder rather than easier" road.
