|
Author
|
Message
|
|
Marco Zinn
|
Friday 22 August 2003 10:34:14 am
Hi,
I like the new installer for 3.2 a lot!
But why can we not install more than one package (site design) in a single DB?
I need 5 or so sitedesigns (package), but all in one DB.
In 3.1, where everything was included by default, this worked. Now, there are packages, but why must I install every package in it's own DB???
Makes no sense to me...
Marco
http://www.hyperroad-design.com
|
|
Jakob Vad Nielsen
|
Friday 22 August 2003 12:08:16 pm
Hi there, 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.
|
|
Jakob Vad Nielsen
|
Saturday 23 August 2003 9:33:50 am
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.
|
|
Marco Zinn
|
Saturday 23 August 2003 11:07:46 am
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???
Marco
http://www.hyperroad-design.com
|
|
Denis Brækhus
|
Sunday 24 August 2003 5:04:33 am
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 ..
|
|
Jan Borsodi
|
Tuesday 26 August 2003 7:07:16 am
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.
--
Amos
Documentation: http://ez.no/ez_publish/documentation
FAQ: http://ez.no/ez_publish/documentation/faq
|
|
RW Wood
|
Friday 05 September 2003 3:31:59 pm
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.
Say it ain't so.
RWW
|
|
Paul Borgermans
|
Saturday 06 September 2003 4:36:47 am
Because the objects in it may have overlapping ID's in the tables. It would corrupt them to install more than one in the same db. When the package format switches to xml data instead of relying on sql dumps, you will be able to use one database. -paul
eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans
|
