On Apr 11, 4:17 pm, Gary Oberbrunner <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > I am on a project that has 2 very distinct parts.
...snip...
> > so whatever I do will require separate set-ups etc.
>
> I have suggested in the past a Trac architecture for this:
>
> * a new table, "project", looking like this:
... snip...
> * make tickets, milestones, and wiki entries...have a project id
...snip...
>
> There was also a proposal
> inhttp://trac.edgewall.org/wiki/TracMultipleProjects/ByProductAndSearch
> which is much more complex but notes that it would be nice to have
> repository paths per project.
>
> I don't think most people seem to value this organizational structure
> though; I haven't ever gotten any interest in implementing it.
There are enough proposals for this sort of architecture that is must
be important. In may case, I've just started deploying Trac within my
organization and this is the only real sticking point to adoption. And
it came up as an objection within the first couple of days in trying
it out with my team. There is a real value to isolating projects -- I
don't think that perspective is at all off-base. But there is also a
real value to being able to aggregate projects in an organization.
In our case, I'm basically following
http://trac.edgewall.org/wiki/TracMultipleProjects/ComprehensiveSolution
but with one twist. The original proposal creates a schema for each
project, and then within a master project uses a plpgsql function to
loop over the projects and create an aggregate master view (so the
project key Gary proposes becomes the schema name, in essence). I've
adapted the scripts to in TracMultipleProjects/ComprehensiveSolution
to maintain inheritance in the non-master projects, so instead of
looping over a potentially large number of tables, I can just query
the table in the master schema. (the actual query will look like
'select bar, relname from foo join pg_class on
pg_class.oid=foo.tableoid;')
I like this approach because it should scale well with queries across
a potentially large number of projects. The postgresql team has not
fully optimized these queries, so even if it is presently no better
than a union in postgresql, it should be better than loading multiple
sqllite instances, it should get better as postgresql further
optimizes.
This approach requires no change to the table schema. Because of the
way inheritance is maintained in postgresql, I do not expect upgrades
to be especially difficult. I suppose that remains to be seen.
I like the ultra-simple deployment that sqllite provided, but I'm
willing to give that up for the scalability to multiple projects.
--
Karl DeBisschop
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
