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.
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. However, the resource table would allow for a resource
belonging to multiple projects. I am not sure that is appropriate yet.
On the other hand, it would allow for independent database versioning
and upgrades.
... 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.
Isn't the Trac-ky thingy just lovely ?
I hope we all can make it better ...
:)
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).
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.
While there is no route to import tickets or environments, we can defer
a decision and see what others make of it.
Cheers,
Gary
