On Wed, Jan 11, 2012 at 10:04 AM, Gary <[email protected]> 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? > yes > > 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). > JFTR - #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 ... :-/ -- Regards, Olemis Facebook => http://www.facebook.com/olemis Twitter => http://www.twitter.com/olemislc (@olemislc) Blog ES => http://simelo-es.blogspot.com Blog EN => http://simelo-en.blogspot.com Quora => http://www.quora.com/olemis Youtube => http://youtube.com/user/greatsoftw Featured article : Identificando números primos con expresión regular en Perl http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html Get a signature like this. CLICK HERE.
