Activity (RSS)

One of my concerns is that having N views to execute on each index update for N associations defined within database might be PIA

The picture you're trying to describe is not clear for me.

Here is an attempt to summarize:

Lets say we have a view for all has_many associations:

(the code...

There is no need in nslurl for container: it is identified by UUID in a key.

For The Very Generic Has Many View, yes, we have to put a meta name along with it...

Please note that "{container}_has_many_{items}" will need to include nsurls for both container and items as well. Is that fine?

I think things get easier when you do name a view like "has_many_{items}" or "{container}_has_many_{items}".

If we'd like to put all the "has_many" assocs int...

Duplicate to #15

http://github.com/yrashk/stroked...

started views-based-associations branch (http://github.com/yrashk/stroked...)

While it might be interesting to do a single view for comments, I think we should pay attention to this kind of special cases later — and as for now we only ne...

Article = Meta.new do
  has_many :comments
end

BlogPost = Meta.new do
  has_many :comments
end

produces =>

View.define(:name => "has_many_comments") d...

do you mean that you want Views be a view itself? Willn't be easier to UUIDv5 views with their name and "view:" namespace?

What about something like

class Views
  def [](name)
    # ...
  end
end

?

Views["some_view"] # => #<{View} name: "some_view" >

Some thoughts on skiplist serialization strategy:

1) Skiplist must be mapped to memory.

2) On modification we write to the end of "operation log".

3) Time t...