Hi Terje, > Even if you all don't want to graph all your resourcess as I do > (I *DONT* GET IT), maybe there still is something I can contribute to..
The main problem with not having such a graph right now is that each subsystem declares its very own data model, something which the generic trac approach tries to overcome, by unifying the resource representation in the underlying data model. As for the rest: sure, having triggers doing the work, i.e. making revision entries, and views for getting the fields for a given resource, would surely speed things up a bit, considering heavy load sites where many updates to the data model are to be expected. So, views and triggers for a more generic resource representation incl. versioning seems to be the way to go for, +1 for that. To be frank, you do not get 1k+/s new issues nor do you modify 1k+/s issues at the same time, neither do you get 1k+ page edits or page adds in the wiki, so this seems not a direct use case for trac since updates to the data model are rather infrequent. What is more important is, at least in my opinion, reading from the database in a most efficient way and rendering the pages to the user as fast as possible. What I do not understand, however, is why you reinvent the row lock mechanisms already available in the system. Of course, SQLITE might not support a SELECT ... FOR UPDATE statement. However, SQLITE features a different locking mechanism that actually prevents two or more simultaneous transactions taking place. See http://sqlite.org/lockingv3.html for more information on that. Other rdbms support SELECT...FOR UPDATE so that we actually do not require a resource locking mechanism ourselves, unless you want to accomplish something different than just preventing concurring updates to specific entities in the database. Of course, this would require the db layer to be extended so as to allow the user of that system to select for update, which is currently not part of its implementation. > ..... G*dd*%川 Carsten WHY would you reply wise words to a post I > EXPLICITLY said I would NOT revive??.... I felt like that it needed some more explanation. -- 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.
