Quick post of my thoughts:

• Is there a list of how the public APIs differ? Would we need to wrap anything? There is a bit of third party code out that based on ANS already.
• "As we typically have rather small trees in ChiliProject and these trees are often read in whole, this probably isn't much of a problem at all." - What about issues? That can be a rather large tree.
• If I recall ANS is also unmaintained or the developers are looking for a new maintainer for it. We should check ancestry's history too to make sure it will be around for some time.
• I'm assuming this would break db schema and query compatibility with Redmine correct?
• Are there any other benefits other than the "consistent tree"? (it's a big benefit, just seeing what else we would get)

I'll have to check some plugins. I think I have one or two that uses (and monkey patches) ANS so I'd like to see how they would need to be changed.

Eric Davis

Eric Davis wrote:

Quick post of my thoughts:

And mine :-)

• Is there a list of how the public APIs differ? Would we need to wrap anything? There is a bit of third party code out that based on ANS already.

The list of API diffs would be my condition too.

• "As we typically have rather small trees in ChiliProject and these trees are often read in whole, this probably isn't much of a problem at all." - What about issues? That can be a rather large tree.

Each issue and its subissues are single trees, not all issues are together in one big tree, so I second the opinion that we "typically have rather small trees".

• I'm assuming this would break db schema and query compatibility with Redmine correct?

Yes, but we're getting there with journalized in 2.0 anyway, so I personally don't care much.

• Are there any other benefits other than the "consistent tree"? (it's a big benefit, just seeing what else we would get)

From a quick look at the library and how it works, I'd say one benefit would be that you could get subtree ordering (partly) from the DB. Currently, if you fetch an issue and it's tree, if you want to get the tree structure out of the DB, you can't get them ordered in any way because you get them out of the DB in the order they were inserted into it. From what I see, ancestry can order subtrees, so you could say "I want this issue, it's tree, and please order each level by start_date". I'm not sure it can do it recursively for every level, but at least it seems to be able to do it for one subtree. (Note that this feature uses ordered hashes though, so it would work on 1.9 and up only according to the README of the lib).

Oh, and if we can tell the library to use a custom attribute for the names it gives the elements in its internal representation, you get a name-based wiki tree "for free" ;-)

Felix Schäfer wrote:

• I'm assuming this would break db schema and query compatibility with Redmine correct?

Yes, but we're getting there with journalized in 2.0 anyway, so I personally don't care much.

I have the same concern with journalized but there are a lot more benefits with journalized. :)

(Note that this feature uses ordered hashes though, so it would work on 1.9 and up only according to the README of the lib).

I thought Rails has an OrderedHash that it subs in for Hash in a few places.

Oh, and if we can tell the library to use a custom attribute for the names it gives the elements in its internal representation, you get a name-based wiki tree "for free" ;-)

Maybe, I'd just be afraid of having to sanitize the page names enough for ancestry. Might work though.

Eric Davis

Eric Davis wrote:

Felix Schäfer wrote:

(Note that this feature uses ordered hashes though, so it would work on 1.9 and up only according to the README of the lib).

I thought Rails has an OrderedHash that it subs in for Hash in a few places.

I thought too that Rails has OrderedHashes, but it seems the plugin doesn't use them, and I'm not sure It'd be worth it to hack it in.

I've queried the maintainer of acestry to see if we could get non-primary-key ancestry keys, which would mean we could get path-based subpages almost for free. See https://github.com/stefankroes/ancestry/issues/68 for the issue.

I was trying to fix one of the sources of corruption [1] in the project tree today but I kept running into issues with awesome nested set.

Are we still thinking about switching to ancestry?

Eric Davis

[1]: The tree is configured to be ordered by project name but if you edit only the name the tree is still considered valid and won't rebuild. I tried to add a validation to the tree to mark it as invalid but the rebuild still isn't working correctly (code). From what I see in the awesome nested set's tests, the :order option really isn't tested that much.

- id, name (root_id, lft, rgt)
* 1 Project A (, 1, 6)
** 2 Project A1 (1, 2, 3)
** 3 A Project is before (1, 4, 5) <<< notice how this should be sorted before id:2. "A Project" <=> "Project A1" 
* 4 Project B (, 7, 14)
** 5 Project B1 (4, 8, 11)
*** 6 Project B11 (5, 9, 10)
** 7 Project B2 (4, 12, 13)
* 8 Project C (, 15, 18)
** 9 Project C1 (8, 16, 17)

I'm all for it, though I'd be even more for it if we received an answer from the maintainer regarding my query above. I know we're not that much better, but I haven't seen much activity on the plugin since june, or we must live with having to fork/maintain it at some point or another.

I've been using it in a comercial project and can say, it works fine. It was the chosen one for trees.

In case it helps someone, I recently needed to rebuild the entire tree so that it was alphabetical.

The following rough patch makes rebuild! do what the name suggests - rebuild the tree.

http://paste.kde.org/430604/raw/