Terje S. | 13 Jul 01:10 2010
Picon

Re: [Trac-dev] Refactoring the Trac data model - relational approach

On Fri, Jul 09, 2010 at 04:14:15PM +0200, Carsten Klein wrote:

> Hi Terje,

Hi Carsten, list

I thought I would find time to post yesterday, but life did not permit.

> This might seem a bit rude, but I must get your intentions right.

Not at all, and certainly not anywhere near my own rudeness-levels...

I will reply merged, as this *IS* my conclusive post.

Followups off-list please, if any, I am *not* reviving.

I post some conclusive thoughts, alas, much has been raised by Carsten
and Christian and otherwise that I will not find time to answer, sorry. 

If anyone has outstanding issues, please contact me, I want them gone.

If the list in general has issues with me, make sure this is communicated,
or I will assume it not to be the case.

I am sorry, if I have stirred up in your community, whether it was my 
stupid words or a sensitive topic or a dangerous combination that caused it.

I will try to not ramble & keep it short.

(Nope, I didn't buy it myself either.)

> 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.

My deployment has a heavily patched core (t-h + local mods), several local
and bsd plugins(most modified), schema mods etc. 

It has not taken any of my time since testing stage...
... save a few minor issues *and* this lengthy thread, that is ;-)

As for my intenions, they were nothing more than to provide a known-good
example model, to be considered against future core requirements, and offer 
my help to tailor it if needed.

This did not happen as intended at all. 

Quite possibly because I did not submit a detailed enough explanation 
of the envisioned system from the start, but rather assuming that its position 
in the core would be assessed by the readers given SQL code.

When I complain, it is only because I have a vision in mind, compared to which
the current system is non-optimal. Sorry that you all had to be the victims of
me falling into such ridiculous trap, and posting /dev/random to the list.....

War was *NOT* my intention in starting the topic, it was love :-(

I will quickly answer a few key points here from the other message, but no
doubt I have left out others, even if they were as worthy of followup.

(I have had some catching up to do, guess why)

> Besides that trac definitely needs an ORM [...]

The value of a relational model is proven, in my opinion.
The value of an ORM is debatable long-term, in my opinion.

Personally, I don't like them. Always gets in the way at some point, or
performs horrible for some operations. But SQLAlchemy does have a very 
impressive feature list, I haven't tried it out.

> And, as far as my understanding goes, it is rather straight forward,
> compared to for example Java based JEE servers.

Fully agree, from what I can gather through my binoculars 8-)

> Major rewrite is out of question with the current main developer base, as
> there are only two and both of them have a RL.

No trouble in understanding this. The rewrite sidetracking was exclusively
useless text that I posted due to questions :-(

Sorry, but some of the posters were hostile towards me also, at least I 
experienced it that way, even if it was not their intention.

Not that I am blaming anyone else, I admit to being the root cause of
all of it, no question, and I wish I could retract some of it but I can't.

Very little relevant information, from anyones perspective including my own
I guess, as to what advantages this would bring in the *long-term* 
have been submitted to the discussion. Nobody appears to have tested the 
provided SQL in practice (not saying you haven't, just that you did not 
speak up about it with any meaningful results or questions, one way or 
the other, except a few cases answered (I think?)).

The list, in general, I feel (sorry) did not really pick up the topic at 
hand. And I *fully* admit my own out-of-line rambles being a large part
of that, apologies, hugs and <3 :* kisses offered by the dozen to anyone who
was offended. Sorry.

It did indeed very quickly turn into either

1) I have not completed the work already
2) Integration approach
3) Backend stuff not appliccable to presented model

And in the list belongs my personal issues, no doubt.

Not so much has been said about the viability, advantages or disadvantages 
of this or *any other* long-term approach to the data modelling strategy, 
as I had hoped in raising the topic.

> This is old talks. And many before you have talked about the subject and
> failed contributing working code.

I have *NEVER* claimed I can provide the code, AT ALL. 

I wish I could contribute that amount of work, but it is not possible :-( 

I have unambigiously offered work to tailor a storage model.

For the week I have been active, I don't see how *so* many of you can
*possibly* expect me to have pursued this work up-front to *any* degree 
of completion, what-so-ever, before attempting to gather support??

Or even seriously considered starting up, at all?

Would you complete this huge amount of work, up-front, risking a final 
commit to magnetic storage??

For what reason, exactly, would I, or anyone else, do that??!

To show I am worthy of contributing or something??!!

Am I *COMPLETELY* off-point here?!

This feels strange at receiving endpoint.

(as must my words have done to you all, sorry)

Can you please take a minute and explain your statements off-list in this
regard, Carsten? I do NOT understand it, at all. I honestly would very much 
appreciate if you can take the time.

I admit to my faults, dear list <3 

Please forgive me for what I did.

Do YOU admit to yours? 

For the first time throughout the thread, Carsten, your posts (in some place
I have massacred out) made me realize I was *MAJORLY* wrong in the iterative
wars, contrary to any post on the topic. Maybe it was Lao Tze.

(one of) 
My error was in spending a *little* effort upfront, outlining in my mind and 
on paper how all the existing subsystems would benefit from a new core model, 
and how they could work together. 

I guess, for unfathomable reasons in retrospect, I expected the list to 
already share my future vision when I posted.

I also *INcorrectly* applied that frame of mind to the iterative approach 
for the single subsystem presented. .. what the f%"... was I thinking.....

My apologies (again) for the resulting shitstorm.

That was a MAJOR mistake on my part.

But you guys sure did catch me off-guard by focusing on these process/
code things that I had not even *considered*, and not the core data model:-(

> Never talk about failure, especially not diminishing the work effort made
> by both Christian and Remy.

I flat-out withdraw this and all other useless words I posted.

Sorry Christian, Remy, list.

(That should leave at least 5 words of *excellent* quality!)

> 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.

I am not quite sure what aspect of the system you are referring to.

I am *not* questioning if Trac can live with the current approach, no doubt
it can. I am questioning if it can realistically grow.

And of course, here is another fatal error that I have made from the first 
post onwards (maybe). I have not even *considered* the fact that growth and 
wide adoption may not be the primary goal of the project, I **BLINDLY**
assumed it was.

If this is the case, I humbly withdraw the remaining +-5 words.

> And, again, about work effort. It is simply an attribute to a, what you
> would call work unit, or a ticket in trac terms.

I don't think I understand how you perceive the model at all.

I will reiterate a little bit on this, since it is in fact ON topic ;-)

Have a quick look here:

http://hansolav.net/sql/graphs.html#graphs

WorkEfforts is the list of nodes (dbo.Node in link)
WorkEffortAssocs is the list of edges (dbo.Edge in link)
WorkEffortTypes declares available node types in the graph
WorkEffortAssocTypes declares available edge types in the graph

The latter two not used in linked examples, but it should be obvious
that they allow nodes and edges to be of different types across the graph.

(Without procedures, you load edge sets to RAM, baked & eaten)

Sorry if that was a waste of time, again. 

> Sorry if I got your intentions wrong, but this is my analysis of the
> current state of affairs so far.

Your posts were the most meaningful replies recieved.

Maybe that was due to the sneaky Lao Tze link also.

(But it does not seem that way to me)

> 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.

Everyone gets my intentions wrong anyway....

This, dear reader, is the reason and intention behind first post:

I submitted what I (still) think is an excellent solution to a long-
standing core problem, wiping the *vast* majority of hard breakdown/
management/estimation problems in a one-go at the storage layer (by 
using a graph, for which all the cost/estimation/path algorithms *already* 
exist, in case that was unclear??GOD!!!!! WHY did I not think to write 
such things in the first post?????). Can you imagine what a Trac plugin 
operating on such an underlying data structure could *DO*?!?!

It would be REVOLUTIONARY!!! :D :D :D (imho)

THAT's the reason I posted.

I did not post because I have time to rewrite Trac core to go with it.

I FAIL to see how you could expect that, sorry.

I was honestly hoping we could do it together. 

Sadly, it failed.

> 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

I fully I agree with your assessment,

It has been *directly* counterproductive in most ways.

I did not intend that at all.

I will not *EVER* rant on your list again.

... I don't know how I fell into such ancient traps ...

Please forgive me, core team & community.

I wanted good, it turned *horrible* :-(

Terje 
 <at> list-domain

--

-- 
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com.
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.


Gmane