Not sure if this is still useful... We've used the ancestry gem (https://github.com/stefankroes/ancestry) with great success. It wasn't used in the matter that you described but might also be a suitable alternative.
Cheers, Jason On 29 November 2011 08:26, Dmytrii Nagirniak <[email protected]> wrote: > > A node is basically a permission (loaded with the information, such as > subject, user, company etc) that is propagated through to the other nodes. > > Is "propagating changes to all child node recursively" a strategy to > improve query performance? > > > Pretty much. So instead of traversing the path "upwards", I can update > it's attributes and query on it. It is not always possible/easy to do > though. > For example: > Company1 includes User1.1, User1.2 > Company2 includes User2 > Company includes User 3 > > And given the permissions: > User1.1 -- Allow read X--> User 3 > User1.2 -- Allow write X--> User 2 > User2 -- Allow write X --> User3 > > In this case User3 should be able to read and write, but only when she is > a part of Company 2 or 3 (both allow write), not Company 1 (only allowed > reading). > > > > If so, you might look at an ActiveRecord extension such as my "Arboreal" > (shameless plug), or DHH's "acts_as_nested_set", to allow efficient queries > on a tree structure. > > https://github.com/mdub/arboreal > https://github.com/rails/acts_as_nested_set > > > I did presentation last year, that included an example of using Arboreal > to query down a hierarchy (e.g. of roles or groups) while joining with > another table (e.g. permissions). See page 10 of: > > http://www.slideshare.net/mdubya/one-project-3-gems > > > I think I remember your talk. I did like it a lot. > I currently do something similar to fetch the subtrees using SQL LIKE and > paths. > The problem there is that I need to query all the parents for a condition. > So that even if I retrieve the subtree, I will have to walk upchain on > each node to verify the permissions. > > If I will be able to propagate all the changes down, then it I can just > query on the nodes themselves. > Although it gets much more complicated as a lot of denormilised data will > be stored... Leading me back to graph DBs :) > > > In any case, thanks a lot to everybody for the suggestions. I am a little > bit better aware of my options now. > I'll actually go and try neo4j... (and will report back if somebody is > interested). > > Cheers, > Dima. > > > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" 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/rails-oceania?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" 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/rails-oceania?hl=en.
