bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [Trac-dev] Bloodhound / Trac Approach
Date Wed, 11 Jan 2012 17:14:18 GMT
On Wed, Jan 11, 2012 at 10:04 AM, Gary <> wrote:
> On 01/10/2012 04:06 PM, Olemis Lang wrote:
>>> and we might be able to avoid changing existing tables by also providing a
>>> table that maps resources to their project.
>> exactly !
>> Even if I didn't mention this before it seems we are in sync (as that's a
>> bit straightforward reasoning ;)
>> In fact I was thinking of considering projects as yet another Trac resource
>> and therefore try to implement such mapping as similar to TracRelations
>> spec [1]_ as possible / needed .
> I am not sure of how much work it would be to go with that. TracRelations is not claimed
to be a complete specification and so it might be better to avoid until it is implemented
in Trac. It is a similar feeling that I get with talk of GenericTrac. I don't particularly
like having to specify that we should write our solution with the expectation of refactoring
but, then again, a move to GenericTrac would result in a refactor of everything else so I
don't see quite so much harm.

Well ... my idea was not to do it *exactly* like in that spec but *as
close as possible* so that when all this will be available in Trac
it'd be easier to incorporate those into Bloodhound (e.g. similar
reports SQL definition , at least not completely different ;)

>>> Or we could just add the extra project field to the appropriate tables.
>>> There is something appealing to me about the latter no-nonsense approach :)
>> What'd be the pros&  cons of (1 - project to resource mapping table) vs (2
>> - extra project field) ?
>> IMO #1 is in sound with the more generic TracRelations proposal (as far as
>> DB is concerned , project-specific behavior is another $0.02 ;) whereas #2
>> breaks the more generic resource relations framework @ the DB level .
> Well, in a sense, anything that should belong to a project does belong to a project,
even if it is the null project (or whatever). That suggests to me that it is a property of
the object rather than a mapping.

ok . I get it.

> However, the resource table would allow for a resource belonging to multiple projects.
I am not sure that is appropriate yet.

That depends on table structure , if resource id field(s) is(are) the
primary key and project ID is a foreign key then there's no chance for
this to happen . Like I said before , similar != exactly .

Nonetheless there are cases to pay attention to as it should be
possible to have CamelCaseName wiki page for both project 1 and
project 2 . AFAICS that's not possible with #1 ...

> On the other hand, it would allow for independent database versioning and upgrades.

... now I recall «practically beats purity» ...

>> ... question may also be reformulated this way : Considering TracRelations
>> is out there , what makes projects so special so as to make an exception
>> with them at the DB-level ?
>> Either way I was thinking of providing projects with at least the following
>>> details
>>>  * name
>>>  * short_name (unique and fixed)
>>>  * description
>>> where the short_name acts as a label in any referencing between projects.
>> +1
>> ... once I submitted project labels proposal [2]_ to trac-dev it was noted
>> (with strong arguments IMO) that resource history may be important to be
>> tracked as well . For project labels it makes sense . Maybe we should
>> consider whether history meta-data might be appropriate for projects&  what
>> events exactly will be tracked during project lifetime .
> I thought that the arguments around that were about changes in name. I should probably
look closer at that but the reason that I want short_name to be fixed is to reduce ambiguity.
That said, a history does not seem unreasonable.

For project labels changes include modification to label-specific
fields + project membership actions (add, remove , ...) which makes
sense (to me) considering the use case provided by Chris Nelson in
trac-dev ...

>> Personally I would also like to see independent ticket numbering per
>>> project but this may be too ambitious.
>> maybe possible with #2 above but definitely not with #1 ; but even if #2
>> allows to do so ...
> Just to check..
>   #1 = project to resource mapping?
>   #2 = extra project field?


> Well, I sort of disagree :) Only in the sense that it would should require an extra bit
of information for both (the ticket number associated with the project).


- #1 implies that ticket number will be the primary key of Ticket
table (just like now) and (project , ticket) association will be
stored in a separate table . Therefore there's no chance to have
ticket 1 in both project 1 and 2 .

- In #2 it's maybe possible i.e. if (projectid , ticketid) is the
primary key of Ticket table .

Nonetheless , consider #2 is the way to go . I just mention an example
. Suppose ticket 1 belongs to project «prj» . References in e.g. wiki
pages should look like ticket:prj:1 . If that ticket is moved onto
another project e.g. then all those references will be invalid .
Nonetheless if ticket ID is unique in the context of the environment
(not the project) then ticket:1 makes reference to that ticket and
reference will be valid even if it suddenly belongs to a different
project .

>>> If we manage this, however, it should simplify the combining of multiple
>>> existing environments into a single project from the user's perspective:
>>> existing commit messages and internal ticket links within a project would
>>> be able to remain consistent.
>> ... maybe it's not a good idea considering your comment above . If ticket
>> has its own identity (like it happens right now as opposite to project ID +
>> ticket ID) references will always be valid (just like it happens right now)
>> , no matter what relations it has with other resources (e.g. projects) and
>> how they change with time . IMO going for #2 + independent ticket numbering
>> may lead to over-complicating a system that just works right now . In any
>> case that doesn't mean that visually e.g. project ID (e.g. short_name)
>> might be displayed in ticket link text.
> That is definitely a good argument and, for the initial work, it might be worth sticking
to that. My reasoning was based on the idea of people wanting to combine existing environments.
Existing references would become invalid if we were to expect to be able to do this.

oh ! maybe I mentioned the same subject once again above ...



Facebook =>
Twitter => (@olemislc)
Blog ES =>
Blog EN =>
Quora =>
Youtube =>

Featured article : Identificando números primos con expresión regular en Perl
Get a signature like this. CLICK HERE.

View raw message