Hi Terje, I have been watching this thread for some time now, and I would like to further investigate your intentions.
This might seem a bit rude, but I must get your intentions right. > CREATE VIEW Tickets AS > SELECT * FROM WorkEfforts WHERE effort_type = [ticket type id] > JOIN [more relevant information]; Now, work effort type by ticket type is clearly a domain idiom. The underlying trac data model does not know about such idioms. Perhaps you are best to go off and implement your own context provider, e.g. /workeffort where you can implement such things using available extension points? The possibility is there, you simply have to discover it and make use of it. For example you could introduce custom ticket fields, and with the use of the [custom] ticket plugin present at track-hacks, you could also limit their use for specific ticket types only. In your custom solution, lets call it a plugin or a collection of plugins thereof, you would then be able to implement what you are seeking for. Hint: ITicketManipulator, IRequestHandler, IResourceManager, trac-hacks, trac.ini. >> come up with a clean "relational" design which improves upon that, >> which is normalized, easy to use, fast, scalable, yet extensible in >> terms of adding/removing custom properties at run-time? Then I'm all >> ears because it's also exactly what I'm looking for. > > Not a "perfect" solution, of course, because of the special requirements > on > sqlite versions and the complexity of the system. But *signifficant* > improvements can be made, as I hope this post will show more clearly.. Hm, stepping back is not an option. If you want the full blown approach, you will have to reinvent the wheel by working over the existing trac classes in order to integrate an ORM or by providing an object relational storage system. Such systems exist, but they do not for python. And such systems can be highly performant, however, they do not exist for python, at least not in an open source software form. > The exact workings of the custom field subsystems, I will supply input on > down the line, when a few other key parts of the design has been done. Its > exact final scope of work is quite unclear to me at the moment. > >> if we would fold everything into custom properties, but that would >> most certainly be detrimental to performance, due to the very simple >> key/value model we use there. So we need something a bit smarter, >> but still as flexible. > What you have failed to do, is to discover the fundamental properties of > the Never talk about failure, especially not diminishing the work effort made by both Christian and Remy. > entities you are modelling. Both the ticket and the milestone represents > work units in a hierarchy, as is favoured by some project management > disciplines, even if you *still* think they don't ;-) Others would call it incidents, but I generally like the idea, as it is also something I have analysed for a solution of mine. But then again, you are calling for work flows, something which is already part of trac. And with the custom workflow plugin available on trac-hacks you can achieve even more so. > This model will help especially in a multi-project scenario. It provides > *FULL* abstraction for *ALL* kinds of hierarchies (via Association > pattern). None of you realize the *first* implications of this model at > all, it seems to me?? You can subdivide this hierarchy forever downwards. > Permissions can be programmed to apply upwards or downwards in different > types of hierarchies present. I think that you are wrong here. In a multi project scenario, trac needs far more than that, especially when all is being stored in a single database backend. Ask osimons at #trac about it, he will tell you. As for the rest of your posting, I must say that your are straight on my line of having a multi project solution with different project methodologies available, but, heck, this is merely a question of how you implement your plugins. And, again, about work effort. It is simply an attribute to a, what you would call work unit, or a ticket in trac terms. As far as my reasoning goes, you have multiple instances of work effort. One that is the estimated, expressed by ticket creation datetime and scheduled end datetime and a custom field for expressing how many people will be involved. And the other would be the real work effort, which is even more complex. Stir it up, little darling, stir it up: Therefore, please provide us with a working model in terms of a data model where all of the information can be stored, that you have in mind, or simply move along the way of implementing your own custom fields and plugins thereof. As far as I can see is that you are stirring up a discussion that will take away current movement and interest in the trac list, by reiterating on long standing feature requests without actually providing any new input in either terms of code or something that can be grasped for developing the platform any further. Merely speaking about work effort does not do the trick. Sorry if I got your intentions wrong, but this is my analysis of the current state of affairs so far. And, if I got your intentions wrong, feel free to embarass me with a document of your own, posted on the trac wiki that would propose the new architecture of future trac, including work effort management and evaluation/estimation. -- Carsten -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
